blupgnup

Mar 162013
 

Ce post fait suite à la première partie de l’installation complète d’un serveur web/mail/ftp/… disponible à l’adresse suivante: Installation Partie 1

A ce stade, vous devez donc disposer d’un serveur sous debian (squeeze) avec le network configuré et un accès ssh (local ou distant.) La première partie de l’installation permet d’effectuer les quelques vérifications fondamentales avant de commencer l’installation. (Entre autre la bonne configuration du réseau, nom de machine etc.)

Il est donc temps de passer à l’installation des différentes dépendances.

Installation de Postfix, Courier, Saslauthd, MySQL, rkhunter, binutils

Nous commençons par la mise en place du serveur mail, de MySQL ainsi que de différents outils nécessaires à la sécurité.

Vous aurez à répondre aux questions suivantes:

General type of mail configuration: <– Internet Site
System mail name: <– nomdeserveur.exemple.com
New password for the MySQL « root » user: <– votremdpsql
Repeat password for the MySQL « root » user: <– votremdpsql
Create directories for web-based administration? <– No
SSL certificate required <– Ok

N’oubliez pas de bien noter votre mot de passe MySQL. Il vous sera nécessaire par la suite.
Nous allons également modifier la configuration de MySQL pour que l’écoute se fasse sur toutes les interfaces du serveur (et non uniquement Localhost)

Commentez la ligne bind-address = 127.0.0.1
Votre fichier my.cnf doit ressembler à cela:

[…]
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
#bind-address = 127.0.0.1
[…]

On peut dès à présent vérifier le bon fonctionnement de MySQL:

Doit renvoyer:
root@server1:~# netstat -tap | grep mysql
tcp        0      0 *:mysql                 *:*                     LISTEN      10457/mysqld
root@server1:~#

Il est également nécessaire de recréer les certificats SSL pour courier. (Ceux-ci sont créés avec le hostname localhost. On souhaite les recréer pour intégrer le nom de notre serveur (nomdeserveur.exemple.com.)
On commence par supprimer les certificats présents:

On modifie ensuite les deux fichiers imapd.cnf et pop3d.cnf en remplacant le paramètre CN=localhost par CN=nomdeserver.exemple.com

[…]
CN=server1.example.com
[…]

[…]
CN=server1.example.com
[…]

Puis on recrée les certificats:

Il ne reste plus qu’à redémarrer le serveur courier:

Installation de Amavisd-new, SpamAssassin, And Clamav

Suit l’installation de l’antispam et antivirus, plus leur dépendances, que l’on lancera avec la commande suivante:

Nous pouvons stopper le processus spamassassin et le supprimer du script de démarrage automatique car ISPConfig a sa propre façon de le lancer via amavisd.

Sécuriser son serveur Debian, les règles de base

 Serveurs dédiés  Commentaires fermés sur Sécuriser son serveur Debian, les règles de base
Août 112012
 

Introduction

Dans l’administration d’un serveur, la sécurité doit être un point essentiel et ne doit en aucun cas être prise à la légère. Votre point d’accès central au serveur est (et restera) votre connexion ssh. Dans le cas d’une distribution linux ‘nue’ vous ne disposerez pas d’autre moyen d’accès à votre serveur lors de la première connexion. Enfin, même une fois complètement fonctionnel, vous serez toujours amenés à vous connecter en ssh à celui-ci. Il est donc important de sécuriser correctement cet accès et il peut également s’avérer pratique d’automatiser la connexion à partir d’une machine suffisamment sécurisée physiquement. Je m’attarderais dans ce post à la configuration de la connexion en ssh depuis Windows via Putty. Putty est un logiciel gratuit aux fonctionnalités multiples. Il permet notamment d’établir aisément des connexions de type telnet, ssh, rlogin/rsh et raw. Vous trouverez le logiciel en téléchargement sur le site de l’éditeur: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Premiers réflexes:

Lors de votre première connexion au serveur, il est important de prendre deux précautions.

  1. Penser à changer le mot de passe du root (qui vous a probablement été transmis en clair, par mail.
  2. Créer un nouvel utilisateur et lui donner les droits suffisants pour l’administration afin d’éviter de travailler en root sur le serveur.

Changer le mot de passe root.

Vous avez de cette façon créé un utilisateur héritant des droits des groupes root et admin. Vous pouvez alors vérifier la connexion avec le nouvel utilisateur (commande ‘su’) puis vous déconnecter de root. Il reste maintenant à sécuriser votre connexion ssh.

Utilisation de putty et connexion à l’aide de clés ssh:

Maintenant que les bases sont posées pour la sécurité de votre serveur, vous pouvez être tenté d’en automatiser la connexion à partir de votre poste de travail principal. Bien évidemment, je ne m’attarderais pas sur le fait qu’il convient, dès que l’on pense à ce genre de solution, de s’assurer de la sécurité du poste de travail en question. (D’autant plus si vous gérez plusieurs serveurs.) Toutefois, il est souvent plus simple de sécuriser une machine locale qu’un serveur distant. (Et si l’IP de votre serveur sera facilement accessible par n’importe qu’elle personne accédant à l’un de vos services, il lui sera bien plus difficile de trouver l’IP à partir de laquelle vous administrez le serveur, ce qui rend l’attaque en ligne plus délicate.)

  1. Génération de la clé SSH: Nous allons tout d’abord utiliser PuttyGen (disponible sur la page de téléchargement de putty) afin de générer la clé ssh. Pour la plupart des cas d’utilisation, les paramètres par défaut suffisent amplement. Ils génèrent une clé SSH-2 (Rsa) qui est la clé la plus sécurisé qu’il est en mesure de créer. La clé est cryptée sur 1024bits qui, à ce jour est considérée comme incassable dans des délais humainement raisonnables. (Il va de soit que la technologie évoluant, il sera toujours nécessaire d’augmenter la complexité de cryptage au fil des ans…) Appuyez sur « generate » et bouger votre souris à l’écran pour générer une clé totalement aléatoire. La clé s’affiche dans le premier cadre. Le champ « key comment » vous permet d’entrer une zone de texte pour identifier votre clé. Le champs « passphrase » vous permet de définir un mot de passe pour protéger l’utilisation de votre clé privée. Si vous n’entrez pas de mot de passe, l’utilisation de la clé ne sera pas restreinte. C’est à dire que n’importe quelle personne ayant accès à votre ordinateur ou ayant réussi à se procurer votre clé pourra l’utiliser pour se connecter librement à votre serveur. L’utilisation d’un mot de passe vous permet ainsi de sécuriser votre connexion mais il vous sera toujours demandé lors de la connexion au serveur. Il vous faut alors sauvegarder votre clé privé et votre clé publique (« save public key » et « save private key ») L’extension de la clé privé doit nécessairement être du type .ppk pour la clé publique, il est communément admis l’utilisation de l’extension .pub
  2. Vous pouvez maintenant configurer Putty afin d’utiliser automatiquement la clé ssh que vous venez de configurer. Après avoir configuré votre Host Name et le port pour votre connexion, qui dépend de la configuration de votre serveur ( je recommande d’utiliser un autre port que le port 22 pour des raisons de sécurité…) Dans la catégorie SSH c’est le menu Auth qui vous intéresse. Dans la zone Private key file for authentification saisissez l’emplacement de votre clé privé (extension .ppk si vous avez suivi les instructions ci-dessus.) Vous pouvez ensuite revenir au menu Session afin de sauvegarder la configuration.
  3. Connectez vous à l’aide de votre mot de passe sur votre serveur. Placez vous dans le répertoire home de l’utilisateur pour lequel vous souhaitez activer l’authentification par clé. Il vous suffit ensuite de créer le répertoire .ssh (s’il n’existe pas déjà) qui contiendra vos diverses clés ssh privées ou publique pour les diverses authentifications que vous mettrez en place. Il vous suffit ensuite de créer le fichier  authorized_keys et d’y coller le contenu de votre clé publique. (Si puttygen est toujours ouvert, vous pouvez copier le contenu de la clé, autrement, il vous suffit d’ouvrir votre clé .pub avec un éditeur de texte et d’en copier le contenu.) Enregistrer le fichier et déconnectez vous du serveur.

Vous pouvez alors tenter de vous reconnecter à votre serveur avec putty et la connexion configurée précédemment. Si vous aviez configuré un mot de passe pour votre clé, celui-ci vous sera demandé à chaque connexion (mais n’est plus transmis au serveur ce qui diminue le risque d’interception du mot de passe) si vous n’aviez configuré aucun mot de passe, vous vous connectez directement au serveur. Si la connexion échoue, votre serveur vous demandera votre mot de passe pour vous connecter manuellement. Vérifier alors la bonne mise en place des clés .ppk et .pub sur Putty et sur votre serveur.

Vous avez ainsi pu sécuriser et automatiser la connexion à votre serveur par ssh. Il existe bien évidemment d’autres méthodes pour disposer d’une connexion sure et ceci n’est pas La méthode fondamentale. Toutefois, elle permet déjà de sécuriser convenablement la connexion et éventuellement de l’automatiser afin d’éviter d’avoir à entrer un mot de passe à chaque connexion.

Juin 252012
 

Après avoir brièvement présenté ISPConfig 3 dans un précédent post : ISPConfig, il est temps de passer à la pratique. Pour cela, la première chose à faire est, bien évidemment, l’installation.

Préparation du serveur dédié pour ISPConfig

Le but de ce post est donc de vous permettre, en partant d’une installation vierge de Debian Squeeze, d’installer tous les services nécessaires pour l’hébergement (Apache 2.2, PHP 5.2, MySQL 5, ftp, mail…) avec une administration par le web à l’aide d’ISPConfig. Bien évidemment, je n’ai rien inventé là et ce tutoriel se base principalement sur ce post (en anglais) du site HowtoForge:
http://www.howtoforge.com/perfect-server-debian-squeeze-with-bind-and-dovecot-ispconfig-3

J’ai très légèrement personnalisé l’installation afin de remplacer Squirrel mail par Roundcube (que je trouve bien plus agréable à l’utilisation) et je vous l’ai traduit en français, voilà tout.

Prérequis

Je suppose dans le début de ce tutoriel que vous disposez d’un serveur fonctionnel sur Debian Squeeze (à jour: 6.0.5) avec un accès ssh et un réseau configuré pour disposer d’une IP statique. (Pour ceux qui voudraient installer Debian sur leur propre machine afin de réaliser des tests @home, vous pourrez suivre le début de la procédure sur le lien cité plus haut afin d’installer Debian avec un accès ssh.) Pour information, même si ce tutoriel devrait fonctionner sur la plupart des distrib sous Debian Squeeze, je précise que mon serveur est installé sur la base d’un noyau 3.2.13 compilé par OVH. Ce n’est pas pour faire de la pub, mais il est intéressant de le noter car cela pourrait expliquer quelques différences par rapport à d’autres versions.

Configuration réseau

Commençons donc par s’occuper du nom d’hôte de la machine. Pour cela, deux modifications sont à faire:
Editez votre fichier /etc/hosts afin d’intégrer le nom de votre choix en regard de votre IP (192.168.0.100 pour l’exemple.)

Ne vous occupez pas de la partie IPv6 (si elle existe dans votre fichier) j’y reviendrais dans un autre post dédié. La partie alias est facultative derrière le nom de serveur. Il s’agit de l’alias local se référant à l’IP en question. (L’alias localhost en revanche, pour l’IP 127.0.0.1, est plus important; beaucoup de programme l’utilisant directement.)
De la même façon, on va modifier le fichier /etc/hostname afin de faire correspondre le nom d’hôte choisi.

Inscrivez le nom d’hôte choisi (si une ligne est déjà présente, la remplacer) et validez la création/modification du fichier en tapant :wq

Afin de vérifier la cohérence des noms d’hôtes, vous pouvez taper successivement les commandes suivantes:

Les deux commandes doivent renvoyer le même nom;

Mise à jour du serveur

Il est également conseillé, avant toute installation majeure, de mettre à jour les paquets Debian. Cela se fait simplement par les commandes suivantes:

(Si aucune mise à jour n’est disponible, assurer vous de bien avoir ajouté le squeeze-update repository dans le fichier /etc/apt/sources.list

Parmi les autres vérifications importantes à faire avant l’installation d’ISPConfig, il convient de s’assurer que bash est le shell par défaut. Pour faire simple, bash et dash sont deux portages  de sh, le shell originel (qui date de 1977.) Bash est plus ancien et a été longuement utilisé par défaut dans les distributions linux quand Dash en est une version plus récente et moins gourmande qui devient donc le standard dans les distributions récentes. Cependant, ISPConfig, ne supporte pas encore dash et c’est pour cela que cette modification est nécessaire. On l’effectuera par la commande suivante:

Use dash as the default system shell (/bin/sh)? <– No

La vérification du shell par défaut se fait de la façon suivante:

doit retourner

Enfin, une dernière précaution qui vous évitera quelques fâcheux problèmes, synchroniser l’horloge avec un serveur NTP (Network Time Protocol.) On installera pour cela les paquets ntp et ntpdate

Cela devrait vous permettre de garder automatiquement votre serveur à l’heure.

Ainsi se termine cette phase de préparation de votre serveur pour l’installation propre d’ISPConfig et de tous les services d’hébergement. Nous n’avons certes pas fait grand chose mais ces vérifications sont importantes afin de partir sur des bases propres pour l’installation. Un prochain post détaillera les phases d’installation des services mails, web, sql et autre avant de pouvoir mettre en place notre interface d’administration.