Installer un serveur OVH avec Debian Lenny « nue »

closeCet article a été publié il y a 14 ans 7 mois 24 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

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 : https://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 🙂

18 comments

  1. Pour l’accès d’OVH, est ce que, par le plus grand des hasards, tu n’aurais pas une clef qui te serait inconnue dans /root/.ssh/authorized_keys ?

  2. Tir groupé :
    – oui le coup de la clé dans le compte root. J’avais zappé. quel con. J’ai pas vérifie la tout de suite mais ca doit être ça en effet. Besoin de vacances 🙂
    – de la a avoir rebooté pour ça ça m’étonnerait, et surtout ils aurait dit pkoi. la ça semblait clair : excès de zèle… Je suppose que ladite clef vient avec l’installation standard qui n’est pas tout a fait « nue » non plus
    – pour RTM oui c’est ce quiest dit. De toute manière je laisse, jajoute simplement mes outils : rkhunter etc…

    Enfin globalement, pour ‘linstant j’en suis content. Le coup du rebooté, en début de vie, c’est encore marrant:)

  3. Concernant les kernels, ce sont des versions optimisées pour les kimsufis.
    OVH tient à jour ses kernel dans un coin de leur FTP, mais c’est aux admin de répercuter les MAJ.
    Suivre le guide pour les majs, rien de bien compliqué : http://guides.ovh.com/kernelinstall

    Voilà un petit script shell qui nous débarrasse des trojans (appelés ça comme vous voulez) placés par OVH, et qui fait un backup des fichiers concernés (au cas ou…) :

    #!/bin/bash

    # not OVH spyware
    if [ ! -d ‘/usr/local/rtm’ ] && [ `grep -c ‘/usr/local/rtm/’ ‘/etc/crontab’` -eq 0 ] ; then
    echo ‘Error : no OVH spyware installed’
    exit 0
    fi

    # backup directory
    RTM_BAK=’/root/rtm_bak.’$RANDOM’/’
    mkdir $RTM_BAK

    # remove softs
    if [ -d ‘/usr/local/rtm’ ]; then
    mv ‘/usr/local/rtm’ $RTM_BAK’/rtm’
    fi

    # delete ssh keys
    cp ‘/root/.ssh/authorized_keys2′ $RTM_BAK’/authorized_keys2’
    > ‘/root/.ssh/authorized_keys2’

    # stop cron
    # */1 * * * * root /usr/local/rtm/bin/rtm 20 > /dev/null 2> /dev/null
    cp ‘/etc/crontab’ $RTM_BAK’/crontab’
    sed -i ‘/\/usr\/local\/rtm\//d’ ‘/etc/crontab’

    Et sin on tenait tant au monitoring de son serveur, on installe MRTG et puis basta 🙂

  4. « Pours les autres, c’est plus dur, vu que c’est toujours en cours d’utilisation.’
    Mais si, mais si, sinon on serait bien embarrasé dans certains cas sur un serveur en prod 😉
    => # mount -o remount /

  5. Ce qui me gêne, c’est que la clef SSH doit être la même pour toutes les machines, sinon ça doit être un peu le bordel à gérer de leur côté => c’est moyen moins quand même.
    Pour RTM, il finira par gicler quand je constaterai que je ne vais jamais voir les graphes et autres du genre car je surveille déjà tout ça via un parc de nagios, cacti et ntop

    Je modifie l’article rapport à 2/3 conneries que j’ai donc écrites 🙂

    1. Oui c’est clair. Encore que je me demande dans quelle mesure ils peuvent/doivent t’apporter du support.
      Maintenant je crois me rappeler que j’avais aussi vu ce type d’accès sur ma dedibox ; y’a quelques années 🙂

  6. Personnellement, j’aimerais passer sur le noyau Debian ou Ubuntu plutôt que le noyau OVH (surtout que je n’aime pas grsec). Mais je n’ai encore jamais eu le courage de tester. En théorie, il faudrait fair un boot-once : grub va booter une fois sur l’autre noyau et revenir au défaut par après, de cette manière tu prends pas vraiment de risque. Mais j’aimerais d’abord avoir des retours d’expérience à ce sujet.

    1. Oui, ce qui est sûr, c’est que le aptitude install linux-image-2.6-686 a foiré. Je n’ai pas du tout cherché, malheureusement.
      Et maintenant, comme tout le monde, la machine est déjà plus ou moins en service…

      Quant à cumuler le changement de kernel + passage à grub, euh… faut vraiment avoir du temps devant soi pour les reboot en mode rescue et les réinstallations

      J’aime pas grsec non plus

  7. En fait, j’avais le noyau normal installé depuis longtemps et sans problème. J’ai juste grub-install /dev/md1 et reboot. Aucun problème.

  8. Pour l’accès ssh en root, il est egalement possible de mettre la valeur de PermitRootLogin à without-password dans le fichier /etc/ssh/sshd_config.

    Cela a pour effet de n’authoriser les connexions SSH en root uniquement si l’authentification est faite par clefs, et de refuser les connexions SSH en root au authentification par login/password.

  9. Le reboot en rescue c’est du PXE, et ça ne monte pas tes disques. Donc que tu ais la clé ou pas, ça change rien.

  10. Quand au coup de zèle suite au ping, j’ai eu pareil 🙂
    Dans le ticket, le gars affirmait que mon serveur était down (alors que SSH/HTTP/SMTP/… étaient dispos).

    Ils sont pas très doués, c’est tout.

  11. Sur les serveurs OVH que je loue, un lien symbolique de /home/mysql vers /var/lib/mysql existe : les bases sont alors stockées sur la plus grosse partition à dispo.

    Idem pour /home/logs vers /var/log.

    Pas très académique, mais ça fonctionne.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.