serveur dédié - partie 1 - commande et réception

Prendre un dédié

Vu l’augmentation de 1&1 et les nouvelles offres kimsufi d’ovh je me suis décidé à passer le pas et à avoir mon propre dédié

  • Avantages:
    • J’ai les version de php, ruby, tomcat… que je veux
    • Je peux avoir autre chose que des services web (openvpn)
    • …
  • Inconvénients:
    • Je dois tout paramétrer et sécuriser

Quelle offre choisir?

Au départ deux KS 2G me semblaient être une bonne idée. Ça fait une puissance correcte pour ce que je veux faire. Et avec deux fois 500G de DD je peux faire du backup (pourquoi pas avec DRBD, vu l’utilisation du dédié ce ne sera pas la bande passante le facteur limittant)
Bon … au momment de passer commande ils passent “sold out”. Et vu le forum de toute façons il m’aurait fallut 2 mois pour être livré. Ce n’était pas prévu, mais un KS 4G fera l’affaire (pour le même tarif que mon mutualisé actuel)

Réception du serveur

Matériel

Les spécif du serveur ayant changé depuis ma commande (j’avais 2 cores de garanti, ce qui n’est plus le cas). J’avais un peu peur:

  • Nb de cores:
    1
    2
    3
    4
    5
    [root@ks ~]$ cat /proc/cpuinfo|grep "core id"
    core id		: 0
    core id		: 0
    core id		: 1
    core id		: 1
    2 coeurs et 4 threads :)
1
2
[root@ks ~]$ cat /proc/cpuinfo|grep "model name"
model name	: Intel(R) Atom(TM) CPU N2800   @ 1.86GHz
  • perf dd
    1
    2
    3
    root@ks3287966 ~$ hdparm -t /dev/sda1 
    /dev/sda1:
     Timing buffered disk reads:  524 MB in  3.00 seconds = 174.60 MB/sec

    L’OS

    J’ai commandé une centos6. Voyons voir a quoi ressemble cette souche ovh

le kernel

1
2
root@ks ~$ ls /boot/|grep bzImage
bzImage-3.8.13-xxxx-grs-ipv6-64

J’en avais vaguement entendu parler: ovh utilise son propre noyau. Plus récent que celui de centos. Ce qui explique certains messages d’erreurs, comme lors de la relance d’IPtables.

De plus grub semble être aussi personnalisé. Un “update-grub2” après un “yum update” du kernel me laisse le kernel d’ovh (car plus récent) -> cf ftp d’ovh

partitionnement

De base 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
root@ks3287966 ~$ df -k
Sys. de fichiers      1K-blocs   Utilisé    Dispo. Uti% Monté sur
rootfs                10190136   1055240   8610608  11% /
/dev/root             10190136   1055240   8610608  11% /
devtmpfs               2011556       328   2011228   1% /dev
tmpfs                  2012020         0   2012020   0% /dev/shm
/dev/root             10190136   1055240   8610608  11% /var/named/chroot/etc/named
/dev/root             10190136   1055240   8610608  11% /var/named/chroot/var/named
/dev/root             10190136   1055240   8610608  11% /var/named/chroot/etc/named.conf
/dev/root             10190136   1055240   8610608  11% /var/named/chroot/etc/named.rfc1912.zones
/dev/root             10190136   1055240   8610608  11% /var/named/chroot/etc/rndc.key
/dev/root             10190136   1055240   8610608  11% /var/named/chroot/usr/lib64/bind
/dev/root             10190136   1055240   8610608  11% /var/named/chroot/etc/named.iscdlv.key
/dev/root             10190136   1055240   8610608  11% /var/named/chroot/etc/named.root.key
/dev/sda2            950190136     23084   950167052  1% /home

Je verrais pour l’instance bind chrootée plus tard.
On vois un partitionnement à l’ancienne. Avec 950Go dans /home!!!
C’est vraiment étrange. Tant qu’à avoir ses propres souches avec un kickstart, autant faire quelque chose de plus “pro” avec du LVM.
La première étape consistera donc à supprimer /dev/sda2 pour un faire un pv!

Le compte root

Avant le premier reboot une clés ssh est présents dans .ssh/authorized_keys. Elle a disparue après un reboot.
Le compte root est accessible directement depuis ssh. J’ai donc ajoute le “PermitRootLogin no” dans sshd_config. J’ai créé un utilisateur et je lui ai donné les droits sudo qui vont bien.

J’aurais aussi pu déplacer ssh vers un autre port pour sécuriser le tout. Mais ce n’est pas efficace. Je verrais peut être plus tard pour du port knocking

La crontab

Une petite particularité: ovh insère une ligne “*/1 * * * * root /usr/local/rtm/bin/rtm” dans /etc/crontab. C’est assez inhabituel de trouver ca à cet endroit. Je trouve cet outil pratique, et je n’ai pas envie de le déplacer en crontab root, je l’ai donc laissé la ou il est.

Hostname

Le dédié vient avec un hostname définit par ovh. Le changer ne pose pas de difficulté.

YUM

RAS c’est ce qu’il y a de plus classique.
J’ai désactivé tous les dépôts en dehors des correctifs de sécurité. Et j’ai ajouté les dépôts EPEL et REMI (pour les maj php et mysql).
Au besoin je les activerais avec un “yum –enablerepos=”

Iptables, SELinux et fail2ban

Iptables et SELinux sont présents et actifs. Surtout ne pas les désactiver …

Vu les attaques sur le port 22 quelques heures après la mise en service du serveur, j’ai installé fail2ban.
La configuration est assez simple. Tout se fait depuis /etc/fail2ban/jail.conf.
Certains services sont pré configurés, il suffit de les activer.
De base au bout de 3 échec, l’Ip est ban 10h. Je n’ai pas modifié ces valeurs. E tant mieux, avec une confusion de DNS entre le mutualisé et le dédié, je me suis ban quelques heures aprés l’activation de fail2ban.

Migration DNS

Avant de commencer à réellement utiliser le dédié il faut transférer les DNS vers OVH (ce n’est pas obligatoire, mais vu que je veux supprimer tout ce qui est chez mon ancien hébergeur). Utiliser une IP n’est pas ce qu’il y a de plus pratique. Et j’ai besoin de “named virtual host”.
L’opération est assez simple. Il suffit de trouver comment désactiver la protection et trouver le code de transfert chez l’ancien hébergeur.
Ça a été assez simple et rapide pour le .fr. Par contre pour le .net il m’a fallu 2 mails de confirmation et attendre 5jours!