[memo/tutorial] Installation serveur dédié CentOS avec Plesk - Webmin - ASL
Ayant fait plusieurs installations ces derniers jours, et étant débutant
dans le monde de l'administration de serveur linux, j'ai pensé faire
une sorte de mémo personnel pour pouvoir réinstaller un serveur.
Tant qu'a faire, autant vous en faire profiter... ^^
Dans l'idéal, j'aimerais par la suite en faire un script bash pour pouvoir faire
toutes ces actions en une fois. Même si le bash est assez simple, je n'ai pas encore
eu le temps de m'y plonger.
1 - Introduction
Nous partons d'une install toute fraîche, il s'agit ici d'une distribution de base : CentOs 5.5 64bits.
Les principaux éléments que nous allons installer :
- Plesk 9.5.4 ou 10 - pour la gestion des virtualhosts
- Webmin - pour la configuration des services depuis internet -p rincipalement pour le module firewall iptables
- Atomic Secured Linux - pour la sécurité et le monitoring
2 - Préparation
Dès la première connexion au serveur en SSH avec les identifiants fournis par OVH,
il convient d'executer des commandes de base notamment pour sécuriser le système :
Mettre à jour les paquets :
Changer le mot de passe root (utilisant 1Password j'aime mettre des mots de passe maître : 50 caractères avec a-zA-Z0-9 et symboles) :
Créer un sudo utilisateur :
Code:
groupadd compteadmin // ajouter un groupe
useradd -G compteadmin compteadmin // ajouter un utilisateur compteadmin au groupe que nous avons crée
passwd compteadmin // définir un mot de passe pour le compte
Vérifier que l'utilisateur est bien créer :
Code:
id compteadmin
uid=10014(compteadmin) gid=10014(compteadmin) groups=10014(compteadmin)
Ajouter le droit sudo à cet utilisateur :
Code:
vi /etc/sudoers
compteadmin ALL=(ALL) ALL
Sécurisation du serveur SSH avec clé privée
La meilleure solution pour sécuriser la connexion SSH est de modifier la configuration par défaut.
Il convient alors d'interdire les connexions avec mot de passe et préférer le système de clé privée.
Au mieux nous devons interdire les login en root et changer le port d'écoute, mais nous sommes chez OVH et ce dernier à besoin
d'un accès en root pour pouvoir accèder à la machine en cas de problème. Nous laisserons donc activer
les login en root et laisserons écouter sur le port par défaut 22, mais pour compléter la sécurisation de l'accès,
nous ajouterons une règle au firewall pour autoriser l'accès à SSH uniquement à OVH et notre IP personnelle.
Pour générer le couple de clé publique privée, rendez-ici :
http://doc.ubuntu-fr.org/ssh#authent..._publiqueprive
Une fois que la clé est installée dans le répertoire /root/.ssh/authorized_keys, il faut maintenant configurer SSH pour autoriser
l'utilisation de cette clé et par la même occasion, désactiver ce dont on n'a pas besoin.
Voici un exemple de fichier de configuration modifié pour notre serveur :
Code:
# user modified sshd_config
# See the sshd(8) manpage for details
# See http://ubuntuforums.org/showthread.php?t=831372
#### Networking options ####
# Using something other than the default port (22) for the ssh server
# can help avoid attacks by script kiddies. I can't tell you how many attempts
# per day my IDS picks up attacking port 22. Some might argue that security by
# obscurity is a bad idea, but I think it works in this case (so does my IDS).
# >> Listen on a non-standard port > 1024
Port 22
# Restrict to IPv4. inet = IPv4, inet6 = IPv6, any = both
#AddressFamily any
# Listen only on the internal network address
#ListenAddress 192.168.1.0
# Only use protocol version 2
Protocol 2
# Disable XForwarding unless you need it
X11Forwarding yes
# Disable TCPKeepAlive and use ClientAliveInterval instead to prevent TCP Spoofing attacks
TCPKeepAlive no
ClientAliveInterval 600
ClientAliveCountMax 3
#### Networking options ####
#### Key Configuration ####
# HostKeys for protocol version 2 - RSA and DSA host (server) keys
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
#Splits up server processes in an attempt to prevent privilege escalation exploits.
UsePrivilegeSeparation yes
# Use public key authentication
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
# Disable black listed key usage (update your keys!)
#PermitBlacklistedKeys no
#### Key Configuration ####
#### Authentication ####
# Whitelist allowed users
AllowUsers root
# one minute to enter your key passphrase
LoginGraceTime 30
# root login enabled because OVH
PermitRootLogin yes
# Force permissions checks on keyfiles and directories
StrictModes yes
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# similar for protocol version 2
HostbasedAuthentication no
# Don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Disable challenge and response auth. Unessisary when using keys
ChallengeResponseAuthentication no
# Disable the use of passwords completly, only use public/private keys
PasswordAuthentication no
# Using keys, no need for PAM. Also allows SSHD to be run as a non-root user
UsePAM no
# Don't use login(1)
UseLogin no
#### Authentication ####
#### Misc ####
# Logging
SyslogFacility AUTHPRIV
LogLevel INFO
# Print the last time the user logged in
PrintLastLog yes
MaxAuthTries 2
MaxStartups 10:30:60
#######
# Allow client to pass locale environment variables
#AcceptEnv LANG LC_*
# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
#######
# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server
# GSSAPI options
GSSAPIAuthentication no
GSSAPIAuthentication no
GSSAPICleanupCredentials no
GSSAPICleanupCredentials no
#### Misc ####
Si vous voulez créer un fichier de configuration optimal, rendez-vous ici :
http://ubuntuforums.org/showthread.php?t=831372,
vous trouverez le fichier de config ci-dessus avec un commentaire détaillé pour chaque option.
Pour modifier la config de ssh le fichier est
/etc/ssh/sshd_config
Redémarrer SSH :
Code:
/etc/init.d/sshd restart
SURTOUT NE PAS FERMER LA CONSOLE SSH ACTUELLE
Au risque de perdre l'accès au serveur si la configuration est incorrecte
Pour tester le bon fonctionnement de la clé, il faut ouvrir une nouvelle console.
Si la configuration est opérationnelle, aucun mot de passe ne sera demandé
et vous serez automatiquement connecté (sauf si vous avez défini un passphrase lors de la génération de votre clé).
La connexion SSH est désormais plus sécurisée et il est plus pratique de s'y connecter.
Astuce : créer un fichier contenant "ssh -p22 -2 root@monserveur" et placer ce fichier sur le bureau ou en raccourci. En un clic vous accédez à votre serveur en root.
3 - Installer Plesk manuellement
Les releases Plesk proposées par OVH sont bien, mais le principal défaut est que l'on ne peut pas installer uniquement ce dont on a besoin.
L'installation manuelle de plesk est très rapide, on peut personnaliser son installation et se débarrasser dès le départ des modules inutiles.
Notez que Plesk n'est pas obligatoire, ceux souhaitant utiliser uniquement Webmin peuvent passer à l'étape suivante.
Pour installer Plesk, suivre les instructions suivantes :
http://www.webhostingsupport.info/ho...anel-on-linux/.
Par expérience, je déconseille l'installation du module Plesk Firewall. Si vous utilisez Plesk 9.5, je vous déconseille également l'installation de AtMail car la version installée n'est pas à jour et pose un sérieux problème de sécurité.
Une fois l'install de plesk terminée, connectons-nous depuis notre navigateur pour configurer plesk. Il suffit de suivre les instructions.
Ensuite, rendez-vous dans votre manager ovh pour y télécharger votre clé Plesk sur votre ordinateur.
Dans Plesk > Gestion des licences, cliquez sur "Upload key" ou "Envoyer la clé".
Si vous avez choisi d'installer Plesk 10, il est possible que la clé ne soit pas acceptée par Plesk, dans ce cas, une solution est d'installer Plesk 9.5.4, installer la clé et ensuite mettre à jour depuis l'interface Plesk en version 10.
4 - Installer le repository Atomic
Si vous regardez un peu les versions des services installés par plesk (http, mysql, php, ...), vous verrez c'est loin d'être à jour.
Malgré un "yum update", aucune mise à jour n'est proposée.
Nous allons donc installer le repo. Atomic proposant les dernieres versions de nos services préférés :
Code:
wget -q -O - http://www.atomicorp.com/installers/atomic |sh
Puis mettre à jour le système :
5 - Installer Webmin
Webmin nous servira principalement pour la configuration du firewall depuis le module "Plesk Firewall". Ce module est beaucoups plus complet que celui proposé par Plesk, les bugs en moins!
Webmin peut également être utilisé pour gérer la configuration de divers services comme Apache, PHP, SSH. C'est utile et plus pratique qu'en SSH et Plesk ne le propose pas.
Pour installer Webmin, c'est très simple :
http://www.webmin.com/
Téléchargement du rpm sur le serveur :
Code:
wget http://prdownloads.sourceforge.net/webadmin/webmin-1.530-1.noarch.rpm
Puis pour installer :
Code:
rpm -i webmin-1.530-1.noarch.rpm
Installation terminée, nous pouvons alors nous connecter depuis
http://XXX.XXX.XXX.XXX:10000
Nous reviendrons dessus plus tard pour configurer le firewall.
5 - Atomic Secured Linux
Atomic Secured Linux (ou ASL) est un bundle proposé par Atomicorp. Il permet de se munir en quelques minutes d'outils permettant la sécurisation de notre serveur.
Les principaux modules installées
- ASL Kernel - PaX/GRSECURITY
- OSSEC - Pour être alerté par email du moindre changement sur votre serveur (et monitoring des logs depuis l'interface web d'ASL)
- CLAMAV
- ModSecurity et ModEvasive
- PSMON
L'interface web d'ASL permet de monitorer la sécurité de notre serveur en temps réel :
- Rapport de vulnérabilités
- Intégrité des fichiers
- Blacklister des IP en un clic
- Geoblocking (bloqué l'accès aux IP d'un pays)
- Evénements de sécurité : permet de voir en temps réel les évènements dans les logs
ASL dispose également d'un accès à un support technique assez réactif, composé d'expert en administration linux. Si besoin, vous pouvez leurs laisser accéder à votre serveur en ssh (installation de la clé atomic) si vous pensez qu'il est compromis.
En revanche, car je ne l'ai pas encore dit, ASL n'est pas gratuit. Il est en effet facturé environ 25$ par mois.
Personnellement, j'ai été séduit dès les premières heures d'utilisation, l'installation se fait en 3 minutes et le résultat est immédiat. D'autant plus que je ne suis pas un warrior en SSH, ni en sécurité linux, je préfère donc déléguer l'installation et la config. de ces outils.
ASL est destiné aux débutants comme aux experts.
Installer ASL
Avant tout, il faut créer un compte sur
http://www.atomicorp.com/ car au lancement de l'installation en SSH, il vous sera demandé vos identifiant Atomic.
Vous bénéficiez d'un essai gratuit de 30 jours, n'hésitez pas à le tester!
Vous pouvez trouver le wiki d'installation ici :
http://www.atomicorp.com/wiki/index....L_installation
Lancer l'installation :
Code:
wget -q -O - https://www.atomicorp.com/installers/asl |sh
C'est tout, il suffit ensuite de suivre les instructions. Vous pourrez bien entendu revenir sur la configuration d'ASL ultérieurement.
N'oubliez pas d'indiquer "yes" lorsqu'il vous sera proposé d'installer l'interface "ASL Web".
Voilà, nous avons installé ASL, nous pouvons désormais nous connecter sur
https://XXX.XXX.XXX.XXX:30000 pour accéder à l'interface web.
Installer le kernel ASL
Notez que l'installation du kernel ASL n'est pas obligatoire mais recommandée pour éviter les failles de type "Critical Risk: Stack is executable. The system is vulnerable to buffer overrun class attacks." ou encore "High Risk: Kernel Module loading is allowed. The kernel allows modules to be loaded on demand. This would allow an attacker to install a kernel module rootkit.".
Voyons le/les kernel installés sur notre système :
Code:
[root@serveur ~]# cat /etc/grub.conf
default=0
timeout=5
title linux centos5_64
kernel /boot/bzImage-2.6.34.6-xxxx-grs-ipv6-64 root=/dev/md1 ro
root (hd0,0)
On voit ici que le kernel d'ASL n'a pas été installé, il faut alors le télécharger :
Dans le fichier /etc/yum.conf, commenter la ligne suivante :
Code:
[root@serveur ~]# vi /etc/yum.conf
#exclude=kernel* grub*
Puis installer le kernel sur le disque :
Notre kernel est désormais installé (2.6.32.27-1.art), il doit être en position 0 :
Code:
[root@serveur ~]# cat /etc/grub.conf
default=0
timeout=5
title CentOS (2.6.32.27-1.art.x86_64)
kernel /boot/vmlinuz-2.6.32.27-1.art.x86_64 root=/dev/md1 ro selinux=0 panic=5
root (hd0,0)
initrd /boot/initrd-2.6.32.27-1.art.x86_64.img
title linux centos5_64
kernel /boot/bzImage-2.6.34.6-xxxx-grs-ipv6-64 root=/dev/md1 ro
root (hd0,0)
Rebooter le serveur en soft :
Après le reboot, vérifier que nous avons bien booté sur le kernel :
Code:
[root@serveur ~]# uname -a
Linux monserveur.com 2.6.32.27-1.art.x86_64 #1 SMP Mon Dec 13 17:27:19 EST 2010 x86_64 x86_64 x86_64 GNU/Linux
Commandes de base
Bien qu'il soit possible de gérer l'ensemble de ces commandes depuis l'interface web, il peut être plus pratique d'utiliser SSH pour les exécuter :
Configurer ASL :
Mettre à jour les règles et signatures ASL :
Scanner le serveur :
Scanner et fixer les erreurs sur le serveur (attention car dans ce cas, ASL modifiera la config de SSH pour interdire les connexions en root) :
Blacklister un ip :
Code:
asl --blacklist XXX.XXX.XXX.XXX
Sinon, pour voir toutes les fonctions :
6 - Configuration du pare-feu
Nous avons déjà bien avancé, nous avons :
- sécurisé l'accès SSH par clé et configurer SSH pour interdire les login par mot de passe
- installé Plesk et/ou Webmin pour gérer nos domaines,
- installé ASL pour la gestion de la sécurité et des vulnérabilités.
C'est bien beau, mais nous restons sujets à des attaques, et dans la configuration actuelle,
par exemple, un simple scan des ports permet à n'importe qui de savoir que SSH tourne sur le serveur.
Aussi, sur notre serveur, le ping est accessible à tout le monde. Est-ce vraiment nécessaire ?
Non dans la plupart des cas.
Il faut alors maintenant configurer le pare-feu présent par défaut dans linux : iptables.
N'étant pas un expert en la matière, l'idée est d'utiliser le module "Plesk Firewall" de Webmin pour configurer nos règles à partir d'une interface web.
Pour les règles :
- Port 22 - SSH - Autoriser l'accès uniquement à partir de notre IP et celle d'OVH
- Port 30000 - ASL - Autoriser l'accès uniquement à partir de notre IP
- Port 10000 - Webmin - Autoriser l'accès uniquement à partir de notre IP
- Port 8443 - Plesk - Autoriser l'accès uniquement à partir de notre IP
- ICMP - Ping - Autoriser le ping uniquement depuis notre IP et celles d'OVH
La configuration des règles depuis webmin est très simple et je ne m'étendrais pas plus sur le sujet,
je vous invite à vous rendre sur le guides OVH pour la config. de SSH et de Ping :
http://guides.ovh.com/fireWall.
Une fois le firewall activé et configuré, nous avons amélioré la sécurité de notre serveur en autorisant uniquement les ports dont nous avons besoin, notre serveur ping uniquement pour OVH et à partir de notre IP personnel, de même pour SSH, Webmin, Plesk et ASL, qui sont accessibles uniquement depuis notre IP.
Il est indispensable d'avoir un IP fixe, au risque de ne plus avoir accès au serveur si notre IP est dynamique et change aléatoirement.
Conclusion
Voilà, vous l'aurez certainement remarqué, c'est plus un "mémo" qu'un véritable tutorial ^^.
Au risque de me répéter, je me considère être un débutant en admin linux, et notre serveur n'est pas forcément complètement sécurisé.
Il s'agit simplement d'énumérer ce qu'il est possible de faire lors de l'install d'un serveur.
D'ailleurs, je vous invite vivement à me corriger si besoin, et n'hésitez pas à partager votre expérience en la matière.
Cordialement,
Busy
