A l’occasion de la location de 2 serveurs dédiés chez OVH, montés en Debian Lenny (what else? comme dirait l’autre), voici un petit tour du propriétaire et du coup un guide minimaliste d’installation/paramétrage d’un tel serveur. Ca fait aussi un petit retour d’expérience sur OVH. Y’a des trucs marrants, vous allez voir.
Il s’agit de 2 serveurs dont j’ai oublié les noms commerciaux, ceux à 69 € et 199 €.
J’ai opté pour Debian “nue”, pas le truc prépackagé qui doit t’amener webmin et ce genre de bazar.

Partitionnement par défaut

Le serveur arrive avec en gros un swap et une partition “/” de quasimment 1 To (la capacité de mon disque) et un /var (dans mes souvenirs) de quelques dizaines de Mo. C’est assez cool pour héberger une base de données, genre des gros fichiers dans /var/lib/mysql…
Aucune restriction type nosuid, noexec, nodev.
Donc je suggère d’abord une réinstallation en mode “je personnalise mes partitions”. L’interface web est curieuse, il faut d’abord affecter un peu de place à /boot, puis de la place (mais pas tout) à /. (pas slashdot, c’est un point pour finir ma phrase )
A ce moment là, l’interface vous permet de nommer et modifier n’importe que point de montage: /home, /var, /tmp, le swap. A votre convenance.
Pour ce qui est des options noexec, nodev, nosuid, que vous voulez peut-être positionner, il faudra modifier /etc/fstab à la main et rebooter ou faire des mount -o remount qui vont bien.

A la fin j’ai ça, dans le cas d’un serveur en RAID 1 logiciel (celui à 69 €, l’autre est en RAID 1 hard, je préfère). Remplacez mentalement /dev/md par /dev/sda si ça vous pose un problème existentiel.

/dev/md2        /       ext3    errors=remount-ro       0       1
/dev/md1        /boot   ext3    errors=remount-ro,nodev,nosuid,noexec   0       1
/dev/md3        /home   ext3    nodev,nosuid    1       2
/dev/md6        /tmp    ext3    nodev,nosuid    1       2
/dev/md7        /var    ext3    nodev   1       2
/dev/sda5       swap    swap    defaults        0       0
/dev/sdb5       swap    swap    defaults        0       0
proc            /proc   proc    defaults        0       0
sysfs           /sys    sysfs   defaults        0       0

Sources logicielles (apt)

Il y a un miroir OVH. Je n’aime jamais trop ce concept, ne sachant pas si c’est à jour ou pas.
De toute manière, il manque le repository “volatile”. Quitte à l’ajouter, je suis revenu aux standards Debian, voici mon /etc/apt/sources.list :

deb ftp://ftp2.fr.debian.org/debian/ lenny main contrib non-free
deb http://volatile.debian.org/debian-volatile lenny/volatile main contrib non-free
deb http://security.debian.org/ lenny/updates main contrib non-free

Un petit aptitude update et aptitude safe-upgrade plus tard, vous voilà à jour.

Kernel

Le kernel par défaut est le 2.6.27.10-grsec-xxxx-grs-ipv4-32 pour un serveur 32 bits. Le patch grsec apporte des modifications de sécurité (mouais) au kernel standard.
Le truc louche est que je ne vois aucun linux-image installé via dpkg -l. J’ai tenté l’installation du dernier 2.6 packagé par Debian (le 2.6.26, via le paquet linux-image-2.6-686), ça a un peu foiré, j’ai lâché l’affaire.
J’ai un peu peur de l’upgrade de sécurité du kernel, qui viendra bien un jour ou l’autre. Pas de paquet qui a amené le noyau (!) et je suis sur les repos autres que les miroirs OVH. Bref à mon avis, le kernel est figé pour longtemps. EDIT: A priori, vu des commentaires, c’est comme chez dedibox : un serveur FTP mettant à jour les noyaux. Supeeeer. Il doit y avoir une mailing-list ou un newsgroup pour suivre les upgrades recommandés, j’espère. C’est le cas chez dedibox.

LILO vs. GRUB

Ils ont choisi LILO. Soit. Je n’ai pas osé mettre GRUB, de peur de foutre la zone avec le reboot en mode rescue. ou de faire sauter (peut-être) le KVM sur IP (ça m’étonnerait quand même). ‘Pas eu envie de tester.
Inconvénient de LILO : penser à taper lilo après un upgrade de noyau. Mais bon, vu la situation décrite ci-dessus…

Accès SSH

Evidemment, accès root autorisé, de toutes les IP.
J’ai changé tout ça : PermitRootLogin no et AllowUsers après avoir créé des utilisateurs locaux. Pour ce qui du classique changement de port, j’ai plutôt opté pour du bridage par IP source sur ce port. Faites comme vous voulez.
OVH peut se connecter en root via clef publique autorisée (installée avec la machine). Si le concept vous plait (et que vous ne virez pas la clef de authorized_keys), il serait judicieux de laisser passer le SSH pour l’IP source qu’ils utilisent (décrite dans le chapitre du firewall ci-après).
Le PermitRootLogin doit être largement incompatible avec ce principe, au passage. Mais bon, on le sait, le RootLogin, c’est mal.

Shorewall (ou iptables)

Là, c’est l’épisode “La mise en place du firewall ou si tu bloques le ping, j’te reboote”. Arg. La cocasse anecdote. Je vous raconte ça comme je l’ai vécu. Les conclusions pour éviter une galère potentielle seront donc à la fin. C’est plus marrant comme ça.
Donc, voici le truc.

(vous pouvez lire mon guide complet sur debian, notamment shorewall, à cette adresse : http://michauko.org/docs/debian_testing/

Après un aptitude install shorewall, il faut configurer Shorewall, avec le postulat de base “je bloque tout sauf ce qui m’intéresse”. Normal. J’ouvrirai le reste à mesure que j’installerai les services (MySQL, apache, mail…)

Les “templates” shorewall pour un serveur à une interface (c’est notre cas) sont amenés par le paquet shorewall-common, dans /usr/share/doc/shorewall-common/examples/one-interface/
Copiez donc tout le contenu dans /etc/shorewall/ et passez en revue tous les fichiers pour que ça corresponde à vos besoins : bridage du SSH sur quelques IP par exemple.
Attention à cette règle (policy) :

$FW             net             ACCEPT

Elle rend possible l’attaque réseau depuis votre machine si elle est compromise. Détailler chaque flux sortant peut permettre d’éviter ça, si votre machine a été compromise juste assez pour faire chier, mais pas assez pour être root, auquel cas l’intervenant fera mumuse avec votre shorewall de toute manière.
Si vous avez besoin d’un fichier “params” vide, il est donné là : /usr/share/doc/shorewall-common/default-config/params.
Une fois votre conf adaptée, modifiez /etc/default/shorewall => startup=1 et relancez shorewall. Testez votre connexion SSH sans perdre l’ancienne session, au cas où la conf n’accepte plus rien, suite à fausse manip…

Cocasse anecdote : une sonde de leur côté (OVH) a immédiatement détecté que mon serveur ne répondait plus au ping=> REBOOT quasi-instantané pour cause de défaillance. O_o woooow. Que ça détecte une “panne”, admettons, que ça force un reboot, PUTAIN NON !!!!!
J’ai eu un ticket quelques instants après m’indiquant qu’il y avait un kernel panic et qu’ils l’avaient donc passé en mode rescue. Moi je veux bien, mais sur la console, y’avait bien écrit “reboot”, et pas le bon gros figeage d’un “kernel panic”. Le type au téléphone m’avait confirmé quelques minutes avant qu’ils avaient forcé le reboot. Bref passons. Ca commence bien la relation client…
Je pense surtout que quelqu’un a eu un excès de zèle et sous couvert d’un ping qui ne répondait pas, m’a rebooté comme un porc la machine, “pour m’aider”, en me la mettant en mode rescue. Ah ouais, super, ça m’aide à mort…
Quelques cris plus tard, un type du service des serveurs dédiés m’indique le “Guide OVH pour le firewall” (http://guides.ovh.net/fireWall). A priori, il me confirme que les machines de monitoring évoquées dans ce guide ne changent pas et qu’il n’y en a pas d’autres en terme de monitoring qui feraient que ma machine serait vu comme défaillante et qui ferait que le mec qui s’emmerde au mois de juillet dans la salle serveur prendrait un coup de chaud et me rebooterait le serveur. Pour m’aider.

Bref, il faut laisser passer le ping pour les machines suivantes : proxy.ovh.net, proxy.p19.ovh.net, proxy.rbx.ovh.net, ping.ovh.net et les 3 premiers octets de votre IP+250/251/249 (3 machines en plus donc).
Plus une machine pour le SSH si vous pouvez avoir besoin d’eux un jour.

Changez enfin les permissions 755 à 750 sur /etc/shorewall

Question : le “PermitRootLogin no” => peut-on quand même passer en mode rescue ? Je le pense, mais bon… car le pass du root est différent. C’est un autre OS qui boote, véritablement, avec uniquement un compte root. Si quelqu’un peut me confirmer ça en commentaire, merci.

Le guide OVH donne la syntaxe iptables pour tolérer le ping de tout ça. Si vous adorez ces longues lignes iptables inbuvables, c’est pour vous. Pour le reste, il y a mast shorewall.
Côté shorewall, avec les fichiers par défaut, il faut comprendre que tout traffic net -> $FW est bloqué par défaut, en “DROP info”, sauf une règle spéciale pour le ping en “DROP simple” – pour éviter de pourrir les logs. J’ai donc ajouté avant cette règle l’autorisation pour les machines de supervision OVH. Ca donne donc :

/etc/shorewall/policy

Inchangé dans cet exemple :

#SOURCE         DEST            POLICY          LOG LEVEL       LIMIT:BURST
$FW             net             ACCEPT
net             $FW             DROP            info
net             all             DROP            info
# The FOLLOWING POLICY MUST BE LAST
all             all             REJECT          info
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

/etc/shorewall/rules

#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE         ORIGINAL RATE            USER/   MARK
#                                                       PORT    PORT(S)        DEST             LIMIT           GROUP

### PING
# ouverture pour monitoring OVH
ACCEPT          net:213.186.50.98       $FW     icmp    # proxy.ovh.net
ACCEPT          net:213.186.45.4        $FW     icmp    # proxy.p19.ovh.net
ACCEPT          net:213.251.184.9       $FW     icmp    # proxy.rbx.ovh.net
ACCEPT          net:213.186.33.13       $FW     icmp    # ping.ovh.net
ACCEPT          net:x.y.z.250       $FW     icmp    # specifique à mon IP : x.y.z.53
ACCEPT          net:x.y.z.249       $FW     icmp    # specifique à mon IP : x.y.z.53
ACCEPT          net:x.y.z.251       $FW     icmp    # specifique à mon IP : x.y.z.53
# des machines à moi :
ACCEPT          net:$une_machine     $FW     icmp
ACCEPT          net:$une_autre            $FW     icmp
#défaut :
Ping/DROP       net             $FW # le reste est en "DROP info". Là on va éviter des logs inutiles

### SSH
# moi, moi et moi :
ACCEPT          net:$une_machine     $FW     tcp     22
ACCEPT          net:$une_autre            $FW     tcp     22
# à la limite, eux :
ACCEPT          net:213.186.50.100      $FW     tcp 22  # cache.ovh.net, probablement inutile, pas de compte dans mon cas

### WEB, utiliser AllowWeb serait plus dans le coup non ?
ACCEPT          net                     $FW     tcp     80,443

### MAIL si besoin
ACCEPT          net                     $FW     tcp     25

#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

/etc/shorewall/params : exemple

# blabla...
#               net     eth0            130.252.100.255 routefilter,norfc1918
#
###############################################################################
une_machine=a.b.c.d
une_autre=e.f.g.h
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE

autres

Dans cet exemple, les fichiers “interfaces”, “zones” etc sont bien tels quels.
Pensez au restart de shorewall et au test afin d’être sûr de toujours pouvoir venir en SSH sur votre serveur.

Autres trucs à faire avant d’aller plus loin

Je passe sur les softs que vous utiliserez ou non : postfix ou exim, snort, rkhunter…
Pensez à cron-apt, apt-listbugs, ntp…

Autre spécificité OVH

Le script /usr/local/rtm/bin/rtm qu’on trouve dans /etc/crontab. Un outil maison de monitoring. Admettons. C’est expliqué là : http://guides.ovh.net/RealTimeMonitoring

A plus tard pour compléter ce retour d’expérience. En bien je l’espère