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 🙂
OVH n’a pas de compte sur ta machine, par contre il demande que tu installes leur clé SSH.
D’ailleurs c’est peut être pour ca qu’ils ont redémarré ton serveur.
Oubli : http://guides.ovh.net/InstallClefOVH
PS : RTM est plutôt pas mal, ca permet de voir tout un tas de choses via le manager, notamment et théoriquement ca doit pouvoir detecter les backdoor et certaines défaillances hard
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 ?
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:)
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 🙂
« 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 /
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 🙂
@michauko:
le coup de la clef ssh sous root je pense que c’est la majorite des hebergeurs qui font ca, et quand tu vois certaines configs je les blame pas.
Ceci dit tu peux tres bien la supprimer:
http://guides.ovh.com/InstallClefOVH (voir la partie desactivation de la clef)
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 🙂
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.
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
Je viens de sauter le pas suite à la lecture de http://forum.kimsufi.com/showthread.php?t=2492
Un simple grub-install – reboot plus tard et je suis sur le kernel par défaut, c’est vraiment plus rassurant.
T’as fait les 2 manips somme toute ?
– lilo => grub
ET passage à un noyau « normal » ?
ou juste lilo => grub ?
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.
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.
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.
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.
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.