Installer vsFTPD

Après avoir réfléchie à la structure des dossiers de notre installation d’un serveur Debian on va pouvoir configurer un serveur FTP.

Installation

Différents serveurs FTP sont disponibles, les principaux sont proFTPD, pureFTPD et vsFTPD. On va prendre ce dernier. Comme d’habitude on commence par installer les paquetages nécessaires :

apt-get install vsftpd libpam-pwdfile

On modifie sa configuration :

nano /etc/vsftpd.conf

Voici en gros à quoi doit ressembler le fichier :

virtual_use_local_privs=YES
guest_enable=NO
user_sub_token=$USER
local_root=/home/$USER/www/public
hide_ids=YES

listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
anon_upload_enable=NO
anon_mkdir_write_enable=NO
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
chown_uploads=NO
xferlog_file=/var/log/vsftpd.log
idle_session_timeout=600
data_connection_timeout=120
async_abor_enable=NO
ascii_upload_enable=NO
ascii_download_enable=NO
ftpd_banner=Welcome to scribox FTP service
chroot_local_user=YES
chroot_list_enable=NO
secure_scroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/private/vsftpd.pem

Pour résumer, on interdit tout ce qui était connexion anonyme, on autorise les utilisateurs locaux et on régle quelques options de sécurité et de bien-être ! Les 5 première lignes du fichier de configuration correspondent à notre utilisation spécifique de sous répertoire par utilisateur vu comme un utilisateur virtuel par le serveur FTP comme décrite dans notre réflexion sur la structure en sous domaines.

Structure

On créé un premier répertoire de test pour notre compte :

mkdir -p /home/jcdenis/www/public

On assigne les bons droits aux répertoires :

chmod -R 755 /home/jcdenis/www
chown jcdenis:jcdenis -R /home/jcdenis/www

On créé un mot de passe utilisateur pour notre compte, comme on a installé Apache on se sert de son utilitaire pour encoder le mot de passe :

mkdir /etc/vsftpd
htpasswd -c /etc/vsftpd/passwd jcdenis

A noter que pour les prochains mot de passe l’option -c (create file) de la commande htpasswd ne sera pas nécessaire.
On indique à PAM d’utiliser les mots de passe de vsFPTD :

nano /etc/pam.d/vsftpd

Son contenu devrait ressembler à cela :

auth required pam_pwdfile.so pwdfile /etc/vsftpd/passwd
account required pam_permit.so

Par défaut vsFTPD a créé des règles pour utiliser les mots de passe du groupe FTP mais ce n’est pas ce qu’on veut donc si ce fichier contient déjà quelque chose il faut tout effacer et ne mettre que ces deux lignes.
On prend en compte le changement de configuration :

/etc/init.d/vsftpd restart

On tente directement sur notre machine de se connecter en FTP et de créer un dossier puis de valider qu’il est au bon endroit :
test_ftp.png C’est parfait on retrouve le comportement qu’on souhaitait.

Protection

Maintenant si on essaye depuis un ordinateur distant, on va avoir un joli : Délai d’attente expiré ou une erreur de ce genre. Si c’est le cas, c’est que vous avez suivi l’étape sur la configuration d’un pare-feu, c’est bien, sauf que maintenant il faut le ré ouvrir aux accès FTP. Pour cela on retourne modifier notre fichier firewall :

nano /etc/init.d/firewall

On ajoute à la fin du fichier les règles nécessaires au protocole FTP :

# FTP
iptables -t filter -A OUTPUT -p tcp –dport 20:21 -j ACCEPT
iptables -t filter -A INPUT -p tcp –dport 20:21 -j ACCEPT
iptables -t filter -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

Et on prend en compte les changements :

/etc/init.d/firewall

On modifie également la configuration de fail2ban pour surveiller vsFTPD :

nano /etc/fail2ban/jail.local

Il faut juste activer la section vsftpd qui devrait alors ressembler à cela :

[vsftpd]

enable = true
port = ftp,ftp-data,ftps,ftps-data
filter = vsftpd
logpath = /var/log/vsftpd.log
maxretry = 6

On n’a pas modifié la configuration des logs et ports donc ce qui était proposé par défaut convient et le filtre existe. Plus qu’à relancer le service :

service fail2ban start

Test

On fait un essai depuis un ordinateur distant :
test_ftp_b.png

Au suivant

Voila, notre configuration du serveur FTP est terminé pour l’instant, on reviendra la compléter lorsqu’on aura installé Dotclear.

Sources

Installer Dotclear

On franchi encore un cap dans l’installation d’un serveur web avec le mise en place de Dotclear.

Comme certains le savent, je suis fan de Dotclear depuis un bon moment maintenant et blablabla… (Je ne suis pas écrivain.) Donc c’est partie pour une installation d’un multiblogs Dotclear. On pourrait faire comme d’habitude en installant un paquetage car oui il en existe un de Dotclear pour Debian, mais on n’est pas comme ça, c’est plus drôle de le faire à la main !

Base de données

On va préparer MySQL pour accueillir la base de donnée de Dotclear, on peut le faire soit depuis la console SSH soit en passant par phpMyAdmin configuré précédemment.
Soyons fou, on va le faire depuis la console de notre VPS Sql. Une fois connecté on lance mysql :

mysql -u root -p

On créé notre table dotclear puis l’utilisateur dotclear qui aura les droits dessus, on n’oublie pas de remplacer IP_DU_VPS_WEB et MOT_DE_PASSE :

CREATE DATABASE `dotclear` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
CREATE USER ‘dotclear’@’IP_DU_VPS_WEB’ IDENTIFIED BY ‘MOT_DE_PASSE’;
GRANT ALL PRIVILEGES ON dotclear.* TO ‘dotclear’@’IP_DU_VPS_WEB’ WITH GRANT OPTION;

Fichiers

Le serveur SQL est prêt, maintenant on retourne sur notre VPS web, il faut télécharger la dernière version stable de Dotclear ( à l’heure ou j’écris ces lignes la dernière version est la 2.5) et la décompresser dans le répertoire qu’on à choisi lors de notre réflexion sur la structure des dossiers :

cd /var
wgets http://donwload.dotclear.org/latest-2.0.tar.gz
tar xzf latest-2.0.tar.gz
rm lastest-2.0.tar.gz
chown -R www-data:www-data /var/dotclear

Notre Dotclear est désormais dans /var/dotclear avec le bon propriétaire.

Sous-domaines

On va créer un premier hôte virtuel pour accéder à l’interface d’administration (et au setup) de Dotclear :

nano /etc/apache2/sites-available/admin.scribox.org

Avec pour contenu :

<VirtualHost *:80>
ServerAdmin contact@.fr
ServerName admin.scribox.org
ServerAlias www.admin.scribox.org
DocumentRoot /var/dotclear/admin/
<Directory /var/dotclear/admin/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
</VirtualHost>

On active le vhost et on recharge la configuration :

a2ensite admin.scribox.org
service apache2 reload

On fait les mêmes manipulations pour créer l’hôte virtuel de themes.scribox.org qui pointe sur /var/dotclear/themes/ .

Dotclear

Si on a bien configuré les champs CNAME des sous-domaines chez notre regisrar, l’interface d’administration de Dotclear est accessible depuis notre navigateur web :
test_dc_admin.png
On configure Dotclear via le wizard avec comme paramètres :

  • Database Type : MySQL
  • Database Host Name : IP_DU_VPS_SQL:PORT_SQL
  • Database Name : dotclear
  • Database User Name : dotclear
  • Database Password : MOT_DE_PASSE
  • Database Prefix : dc_

Ne pas oublier qu’on a changé le port de connexion au serveur MySQL lorsqu’on l’a installé, il faut donc le préciser dans le nom d’hôte de la base. (Database Host Name)
Depuis l’interface d’administration de Dotclear on créé un blog correspondant à notre compte et on utilisera les sous-domaines de scribox.net pour les blogs :
dc_first_blog.png

Blog

Pour l’instant la partie public du blog n’est pas accessible car il faut qu’on créé le vhost correspondant, on commence à avoir l’habitude :

nano /etc/apache2/sites-available/jcdenis.scribox.net

<VirtualHost *:80>
ServerAdmin contact@.fr
ServerName jcdenis.scribox.net
ServerAlias www.jcdenis.scribox.net
DocumentRoot /home/jcdenis/www/
<Directory /home/jcdenis/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
</VirtualHost>

a2ensite jcdenis.scribox.net
service apache2 reload

Si on vérifie dans notre navigateur web on se rend compte qu’il manque encore quelque chose !
dc_blog_noindex.png
Il faut ajouter un index avec la configuration du blog :

nano /home/jcdenis/www/index.php

<?php
define(‘DC_BLOG_ID’,’jcdenis’);
require ‘/var/dotclear/inc/public/prepend.php’;
?>

Thèmes

Si on vérifie dans note navigateur web on se rend compte qu’il manque encore quelque chose !!
dc_blog_notheme.png
Il n’y a pas de thème. Il faut modifier les paramètres de notre multi-blogs pour utiliser notre adresse de thèmes, pour cela on va dans le plugin aboutConfig et on modifie theme_path et theme_url comme suit :
dc_aboutconfig_theme.png
On vérifie une nouvelle fois dans notre navigateur web et la, miracle, ça fonctionne !
dc_blog_withtheme.png

URL

Il ne reste qu’une chose à faire: Avoir de belles URLs pour notre blog, en effet pour l’instant on a des …net/index.php?plop… et il serait plus joli d’avoir …net/plop…, pour cela on va utiliser la réécriture d’URL qu’on a activé lors de l’installation d’Apache en ajoutant un fichier .htaccess à la racine de notre blog et en modifiant les réglage du blog :

nano /home/jcdenis/www/.htaccess

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) index.php?$1

Et depuis l’interface d’administration de Dotclear dans les paramètres du blog on supprime ”index.php?’ de la fin de l’URL du blog et on passe en QUERY_STRING.
dc_blog_url.png
On ne tient pas compte de l’avertissement et on vérifie dans notre navigateur web avec par exemple l’adresse
http://jcdenis.scribox.net/archive
C’est quand même plus joli comme URL !
Si jamais on a une erreur 500, soit le mod_rewrite d’apache n’est pas activé (il faut alors faire les commandes a2enmod rewrite suivi de service apache2 restart ) soit on s’est trompé dans note vhost (on n’a pas mis AllowOverride All ).

Notre premier blog est en ligne !

Sécurisation

Pour être un peu plus tranquille, on va faire une revue des permissions et propriétaires de Dotclear.
On vérifie que notre Dotclear appartient bien à Apache puis on lui donne toutes les permissions ce qui permettra les mises à jour automatique, et pour les autres on laisse seulement les permissions de lire et exécuter :

chown -R www-data:www-data /var/dotclear/
chmod -R 755 /var/dotclear

On vérifie également la présence d’un fichier .htaccess contenant Deny from all dans les répertoires /var/dotclear/inc/ et /var/dotclear/plugins. On force la partie administration de Dotclear à utiliser SSL (protocole https), pour cela on génère un certificat SSL sur notre machine :

openssl req $@ -new -x509 -days 365 -nodes -out /etc/apache2/apache.pem -keyout /etc/apache2/apache.pem
chmod 600 /etc/apache2/apache.pem

On modifie le virtual host correspondant au sous-domaine de la partie administration de Dotclear:

nano /etc/apache2/sites-availabe/admin.scribox.org

<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /etc/apache2/apache.pem

ServerAdmin ma.vrai@.mail
ServerName admin.scribox.org
ServerAlias www.admin.scribox.org
DocumentRoot /var/dotclear/admin/
<Directory /var/dotclear/admin/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
</VirtualHost>

Ici on a ajouté l’écoute du vhost sur le port 443 (dédié à SSL) et on a dit d’utiliser le certificat créé un peu plus tôt.
On vérifie que le module SSL d’apache est chargé :

ap2enmod ssl

On modifie notre fichier de configuration de Dotclear pour lui dire d’utilise le mode https en ajoutant la directive à la fin avec la commande :

echo "define('DC_ADMIN_SSL',true);" >> /var/dotclear/inc/config.php

On redémarrage apache :

service apache restart

A partir de maintenant il sera obligatoire d’utiliser https:// pour accèder à la partie admin, sinon on sera redirigé vers la partie public du premier blog.

Optimisation

On ajoute à notre Dotclear deux plugins de gestion de cache pour cela dans l’interface d’administration de Dotclear, dans le menu SYSTEME=> Installateur DotAddict.org => Rechercher : on recherche le mot cache et on installe les plugins memCache et staticCache.
Puis dans la console SSH on modifie le fichier de configuration de Dotclear :

sed -i "/?>/i define('DC_SC_CACHE_ENABLE',true);" /var/dotclear/inc/config.php
sed -i "/?>/i define('DC_SC_CACHE_DIR',dirname(__FILE__).'/../cache/static');\n" /var/dotclear/inc/config.php

Résumé

Pour résumer, que faut-il pour accueillir un nouveau blog sur notre plateforme ? Un nouvel utilisateur système, son arborescence de répertoires, son compte FTP, son sous-domaine, son vhost, son blog. On pourra dans quelques temps essayer de faire un script de création de blog qui fera tout d’un coup…

Au suivant

Notre serveur prend vie, sa configuration se complète petit à petit, mais encore faut il le maintenir à jour.

Pour aller plus loin

Structure en sous domaines

Avant d’aller plus loin dans notre installation d’un serveur Web on va faire un point.

Qu’a-t-on fait ?

Pour commencer on va voir ce qu’on a déjà fait. Et à vrai dire pour le moment on a juste posé les bases de notre serveur. On a apporté une petite (mini) touche de sécurisation en configurant SSH, iptables, netfilters, fail2ban, rkhunter… Et on a installé ce qu’on appelle communément le package LAMP composé ici de Debian, Apache 2, MySQL 5.1, PHP 5.3 auquel on a ajouté phpMyAdmin. Il reste encore beaucoup de chemin avant d’avoir tous les outils en main, il manque un serveur FTP, la gestion des sauvegardes, et un CMS ou assimilés. Il faudrait aussi monter d’un cran coté sécurité et également coté performance mais pour l’instant on n’est pas (je ne suis pas) assez calé. Mais maintenant qu’on sait qu’on a des chances de s’en sortir, il est temps de faire un pause !

Que cherche-t-on à faire ?

Pas de grandes ambitions, loin de la, on vient du monde des mutualisés et on a aucune prétention à passer pro du serveur autogéré. Tout ce qu’on veut, c’est progresser un peu sans pour autant se casser la tête d’où le choix du VPS: pas cher, pas de souci de matériel, juste plus d’autonomie. Sur nos hébergements mutualisés, que faisait-on ? Un peu de CMS ? Et bien ici on va faire pareil ! Personnellement je suis fan de Dotclear alors on va partir la dessus.

Comment le faire ?

La il ne faut pas se tromper car c’est le moment ou il sera difficile de changer de cap en cours de route. On va voir la structure des comptes, dossiers, domaines qu’il va falloir mettre en place si on souhaite héberger plusieurs blogs par exemple.
Tout d’abords comment fonctionne Dotclear ? C’est assez simple et pratique, on a un répertoire de base qu’on peut mettre n’importe ou avec un bémol pour la zone d’administration qui doit être accessible depuis notre navigateur web, on va de plus faire le choix d’utiliser un seul répertoire commun à tous les blogs pour les thèmes, ce répertoire doit également être accessible depuis le web, ensuite c’est la fête (c’est du bonheur) on aura un répertoire par blog contenant le fichier index et un sous répertoire de média. Il est alors très facile d’imaginer la concordance entre blog, répertoire, sous domaine et utilisateur. On va pimenter un peu la chose en tentant d’ajouter un accès (utilisateur) FTP (privé) par répertoire public.
Donc on aura une arborescence par blog qui ressemblerait à cela :

  • /home/nom_du_sous_domaine/www/public

L’utilisateur sur la machine sera nom_du_sous_domaine, il sera l’administrateur du blog du même ID, le sous domaine pointera sur /www en HTTP grâce à un vhost Apache et l’admin aura un accès FTP à /public. Pour l’instant on ne lui donne pas d’accès SSH. A côté de cela, pour les parties communes, on utilisera les vhost pour donner accès à l’interface d’administration de Dotclear et aux thèmes, ce qui devrait donner une concordance dans ce style :

  • themes.srcibox.net qui pointera sur /var/dotclear/themes/
  • admin.scribox.net qui pointera sur /var/dotclear/admin/

Comme @ me l’a fait remarquer, ne pas oublier que les répertoires /var/dotclear/cache et /var/dotclear/themes devront être accessibles en écriture pour l’utilisateur www-data. A noter que pour l’instant on laisse la gestion des domaines et sous-domaines à notre registrar, un jour peut-être on le fera directement sur la machine.

Au suivant

Les bases sont posées. On a plus qu’à se documenter sur les droits utilisateurs, la configuration d’un FTP et on revient faire tout ça.

Remarque

Après une dizaine d’article consacré à l’installation de nos serveurs, on a pris l’habitude de la console et de son fonctionnement, il serait bien de progresser de ce coté aussi en utilisant de nouveaux outils et lignes commandes afin de gagné du temps.

Installer phpMyAdmin

Sur notre chemin vers l’installation d’un serveur web, après avoir installé MySQL sur le second VPS, on va revenir sur notre VPS Web pour installer phpMyAdmin.

Utilisateur MySQL

On va quand même retourner un instant sur notre machine dédiée à SQL pour ajouter un utilisateur à MySQL avec tous les droits afin de pouvoir nous connecter depuis notre VPS Web et pouvoir installer phpMyAdmin à distance. Donc sur notre VPS SQL :

mysql -u root -p

On entre le mot de passe du root mysql (pas celui du système) et comme on va limiter l’accès distant à MySQL uniquement à notre VPS web, il faut remplacer IP_DU_VPS_WEB dans la commande suivant par l’IPv4 de notre machine Web et MOT_DE_PASSE pour un mot de passe de ce nouvelle utilisateur :

mysql> CREATE USER ‘vpsweb’@’IP_DU_VPS_WEB’ IDENTIFIED BY ‘MOT_DE_PASSE’;
mysql> GRANT ALL PRIVILEGES ON *.* TO ‘vpsweb’@’IP_DU_VPS_WEB’ WITH GRANT OPTION;

Installation de phpMyAdmin

On revient sur notre machine Web et on installe le paquetage qui va bien :

apt-get install phpmyadmin

On lui indique qu’on utilise Apache 2 puis on lui dit qu’on ne veut pas configurer automatiquement la base de données.
Ensuite on relance la configuration de phpMyAdmin :

dpkg-reconfigure phpmyadmin

Et cette fois on lui demande de réinstaller la base de données. Il nous demande si le serveur MySQL est local (unix socket) ou distant (tcp ip), dans notre cas ce sera distant. On lui indique l’adresse IPv4 de notre machine SQL et le port qu’on lui a configuré. Ensuite on lui indique l’utilisateur vspweb créé précédemment et son mot de passe puis un utilisateur qui aura tous les droits sur les tables de phpMyAdmin ainsi qu’un mot de passe et le nom de la base relative à phpMyAdmin. Les valeurs proposées par défaut conviendront. Si le message “populating database via sql… done” apparait c’est qu’on a réussi.
conf_pma_ok.png
On vérifie en se connectant à phpMyAdmin via notre navigateur :
test_pma_ok.png
Maintenant que ça fonctionne on fait un peu de ménage en retirant tout ce qui a rapport au setup. On supprime la partie Directory en rapport à setup dans le fichier :

nano /etc/phpmyadmin/apache.conf

Puis on efface tout le répertoire setup :

rm -rf /usr/share/phpmyadmin/setup

Au suivant

Finalement on ne sent sort pas si mal, et après quelques billets d’exercices, on commence à prendre le coup. Ça va être le moment de faire un break.

Installer MySQL

On avance dans notre installation de serveur web avec la mise ne place de MySQL.

Installation

Au fils des exercices, on fini par avoir l’habitude de commencer nos manipulations avec l’installation du paquetage de base. Ici celui du serveur MySQL :

apt-get mysql-server

Comme la machine autorisera un accès distant à MySQL il faut mettre un mot de passe fort !
Puis on l’arrête le temps de faire nos modifications :

service mysql stop

On va modifier la configuration de MySQL pour autoriser les connexions externes en commentant l’option bind-address et en modifiant son port :

nano /etc/mysql/my.cnf

conf_mysql.png
On note bien le port qu’on a choisi car il nous servira à plusieurs reprises.
On modifie notre pare-feu pour autoriser le passage des connexions Mysql en ajoutant deux règles à la fin du fichier firewall avec l’IPv4 de l’autre machine :

nano /etc/init.d/firewall

# Mysql
iptables -t filter -A OUTPUT -p tcp -d xxx.xxx.xxx.xxx –dport 3366 -j ACCEPT
iptables -t filter -A INPUT -p tcp -s xxx.xxx.xxx.xxx –dport 3366 -j ACCEPT

On ajoute les mêmes règles sur notre VPS dédié à la partie web en pensant bien à mettre le port choisi plus haut et en remplaçant xxx.xxx.xxx.xxx par l’IPv4 de l’autre machine.
On n’oublie pas de prendre en compte les changements sur les deux machines :

/etc/init.d/firewall

De même pour Mysql :

/service mysql start

Au suivant

MySQL étant installé, on va maintenant se trouver un outil de gestion de base de données.

Sources

Préparation du deuxième VPS

Dans l’installation de notre serveur web, on veut une petite particularité qui consiste à installer MySQL sur un serveur distant.

Je ne sais pas si je vais arriver à mes fins ni même si cette solution sera viable, mais pourquoi ne pas essayer, ça nous entrainera. On va d’abords préparer le terrain de la même manière que pour le premier VPS à quelques détails près car ce deuxième VPS ne servira que pour MySQL, du moins au départ. Allé hop, on enchaine les commandes, si on ne se rappelle plus à quoi elles servent, il suffit de retourner voir le détail dans les billets précédents.

Installation

On met à jour :

apt-get update
apt-get upgrade

On installe un ou deux trucs nécessaires :

apt-get install nano rkhunter fail2ban

On va laisser cette machine en Anglais mais on relance quand même la configuration pour inhiber les messages d’erreur de Locales et on met au bon fuseau horaire le serveur :

locale-gen en_US.UTF-8
dpkg-reconfigure locales
dpkg-reconfigure tzdata

On modifie le nom court de la machine, la première s’appelait scriboxWeb, on va donc appeler celle la scriboxSql dans les fichiers :

nano /etc/hostname
nano /etc/hosts

On ajoute notre utilisateur non root :

adduser jcdenis

On modifie notre configuration SSH en changeant le port de connexion, interdisant root et en ajoutant notre nouvel utilisateur dans le fichier :

nano /etc/ssh/sshd_config

On configure notre adresse mél pour le compte root dans :

nano /etc/aliases
newaliases

On modifie le bash root pour envoyer un mél lorsqu’une connexion se fait sur son compte :

nano /root/.bashrc

On va configurer notre pare-feu en laissant le minimum de ports sans surveillance, on y reviendra plus tard, et on n’oublie pas de vérifier notre port SSH personnalisé :

nano /etc/init.d/firewall
chmod +x /etc/init.d/firewall
update-rc.d firewall defaults

On modifie la configuration de rkhunter avec notre mél :

nano /etc/default/rkhunter

On configure fail2ban en modifiant notre port SSH dedans :

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
nano /etc/fail2ban/jail.local

Et si on est certain de ne pas avoir fait de bêtises, on redémarre le serveur :

reboot

En employant la méthode rapide et sans essai, si jamais on s’est trompé et qu’on n’arrive plus à se connecter, on a pas d’autres choix que de réinstaller la machine…

Au suivant

Notre deuxième machine est prête à accueillir ces programmes, c’est partie avec l’installation de MySQL.

Installer PHP 5

Dans notre série de billets sur l’installation d’un serveur Debian, après l’installation d’Apache 2 vient tout naturellement celle de PHP 5.

Installation

Tout comme pour Apache, au premier abords l’installation de PHP 5 est très simple, il suffit d’installer le paquet avec :

apt-get install php5

apt-get va installer en même temps quelques paquetages nécessaires au bon fonctionnement de PHP. Bon ok ça vous parait un peu light quand même ? Moi aussi, alors on va ajouter quelques trucs à PHP, c’est parti :

apt-get install php5-curl php5-gd php5-json php5-mcrypt php5-memcache php5-mhash php5-mysql php-pear php5-tidy php5-xmlrpc php5-xsl

Pour l’instant mon but final est d’installer une ferme de blogs du genre Dotclear, donc pas besoin de tout mais quelques modules indispensables quand même. De toute façon il est simple d’en ajouter plus tard si le besoin s’en fait sentir. Mais revenons à nos moutons.
Avant d’oublier, on va installer memcache et modifier sa configuration :

apt-get install memcached
nano /etc/memcached.conf

On va passer la mémoire à 256Mb (on baissera si jamais c’est trop.) et le nombre de connexions simultanées à 512 :
conf_memcached.png

Configuration

Maintenant il faut modifier un peu la configuration de PHP pour qu’il soit plus propre :

nano /etc/php5/apache2/php.ini

Je ne met pas de copie d’écran ici, le fichier est beaucoup trop long, mais voici quelques valeurs à trouver et à modifier, et ça ne fait pas de mal de parcourir ce fichier pour voir ce qu’il contient :

short_open_tag = Off
asp_tags = Off
safe_mode = Off
expose_php = Off
variables_order = “GPCS”
request_order = “GP”
register_globals = Off
magic_quotes_gpc = Off
magic_quotes_runtime = Off
file_uploads = On
upload_max_filesize = 8M
max_file_uploads = 10

Comme on est chez nous, on va monter un peu la taille de upload_max_filesize mais on va descendre le max_file_uploads (on est en HTTP pas FTP…) Et voila ça devrait être pas mal.
On enregistre et on relance apache :

/etc/init.d/apache2 reload

On va vérifier que PHP fonctionne en créant le fameux fichier phpinfo :

echo '<?php phpinfo(); ?>' > /var/www/scribox.org/phpinfo.php
  • TIPS : On gagne du temps en écrivant directement notre code dans le fichier avec la commande echo.

On va vérifier tout ça dans notre navigateur web :
phpinfo.png
Yeaah, un PHP tout neuf, tout fonctionnel. On parcours un peu la page pour voir ce qu’il y a d’installé, puis on efface le fichier, c’est mieux :

rm /var/www/scribox.org/phpinfo.php

Au suivant

Bon cette fois je crois qu’on est bon. On va pouvoir s’attaquer à la deuxième machine.

Sources

Anti rootkit

On enchaine l’installation de notre serveur avec la mise en place d’outils anti rootkit.

C’est quoi ?

Un rootkit, comme son nom le laisse penser, permet à celui qui s’en sert de se connecter avec le compte root sur notre machine et donc d’avoir les pleins pouvoirs. Je tiens à préciser que si notre machine est compromise, les outils qu’on pourra mettre en place ne serviront à rien car ils pourraient avoir été modifié par cette personne. Néanmoins cela va nous permettre d’avoir une idée de ce qui se passe sur notre machine. Autre information à prendre en compte, les anti rootkit font souvent des alertes pour rien (faux positifs), mais il est assez simple de savoir si c’est nous qui avons modifié / mis à jour/ installé ou non un programme. Ici on va juste installer un anti rootkit, mais il existe de nombreuses autres méthodes plus fiables mais plus complexes comme par exemple l’installation d’un IDS. Bref, on va faire simple. Les deux principaux outils de base sont chrootkitet rkhunter. On prend rkhunter (car je rappelle que je suis seul maitre de mes choix!) qui analyse les changements apportés à notre système.

Mise en place

C’est parti, on installe rkhunter :

apt-get install rkhunter

Et on édite son fichier de configuration :

nano /etc/default/rkhunter

Soit on laisse l’envoie de mél passer par notre configuration du compte root, soit on l’envoie directement (je l’ai mis en direct sur ma machine) et on vérifie que le cron se lance tous les jours :

REPORT_EMAIL=”ma.vrai@.mail”
CRON_DB_UPDATE=”yes”
DB_UPDATE_EMAIL=”no”
CRON_DAILY_RUN=”yes”
NICE=”0″

Pour ignorer des messages d’alerte inutiles on désactive un test dans le fichier de configuration de rkhunter :

nano /etc/rkhunter.conf

DISABLE_TESTS=”os_specific suspscan hidden_procs deleted_files packet_cap_apps apps”

On a ajouter à cette directive ‘os_specific’ qu’on ne souhaite pas tester.
Voila notre petit anti rootkit est en place. Pour lancer un scan manuellement (qui prend 2 ou 3 minutes) on utilise la commande :

rkhunter -c -sk

Il est également préférable de mettre à jour la base de notre anti rootkit après de gros changements sur notre serveur, cela évitera de se prendre une flopée de faux positifs. Une fois nos installations / modifications faites, il suffit de lancer les commandes :

rkhunter --propupd
rkhunter --update

Au suivant

On enchaine avec encore un peu de sécurité et un outil de bannissement dans le prochain billet.

Sources

Première connexion

Premier pas de notre découverte des joies d’un serveur Linux, on va se connecter à notre VPS.

Une fois notre VPS commandé avec la distribution Debian Squeeze 64bits nu pré-installée, nous devrions recevoir un mél indiquant le nom de la machine, ses adresses IPv4 et IPv6 ainsi que le mot de passe root, on va donc se connecter en SSH dessus.

A la maison

J’utilise le logiciel PuTTY car je suis sous Windows chez moi. Quand je vous dis que je n’y connais rien en Linux, ce n’est pas des salades.
Commençons par entrer l’IPv4 du VPS_WEB, on vérifie que le port est bien 22 puis on y va avec Open.
putty_enter_ip.png
PuTTY ouvre alors une fenêtre d’alerte sur le certificat, on est d’accord, on comprend le risque, blablabla, on se retrouve sur la console qui me demande un login, on entre le nom d’utilisateur “root” (c’est dieu sur votre VPS) et son mot de passe reçu plus tôt dans le mél. La console est votre nouveau bureau ! On verra on fils du temps ce qu’il y a dessus, à part du noir…
putty_enter_root.png

Sur le serveur

Notre machine étant toute fraiche, il faut la mettre à jour, et la on n’est pas sous Windows! Deux commandes pour réaliser cela :

apt-get update
apt-get upgrade

On répond oui (Y) à la deuxième commande, ça va mouliner un peu pour les deux commandes puis c’est fait, notre système est à jour. Cette opération sera à faire régulièrement sur notre serveur pour le tenir à jour.

  • TIPS : apt-get est le gestionnaire de paquetages (programmes) sont Debian, il permet d’installer, de mettre à jour et de désinstaller des logiciels.

On en profite pour tester l’installation d’un programme ou paquet comme ils disent :

apt-get install nano

Hop, on vient d’installer un éditeur de texte ! Celui qu’on va utiliser tout au long des articles.
L’utilisation de nano dans notre cas va se limiter à quelques commandes pour ouvrir un fichier il suffit de faire :

nano /var/plop.waza

Ce qui ouvrira le fichier “plop.waza” du dossier “var”, même si il n’existe pas encore.

  • TIPS : Une fois dans nano, pour enregistrer il suffit de faire la combinaison de touche Ctrl-x puis y (pour yes ou o pour oui si c’est en français) puis la touche entrée. Si on ne veut pas enregistrer on répond n (pour no).

On poursuit par quelques manipulations simples pour se familiariser avec notre nouvelle amie la console.
Pour l’instant on est toujours avec notre compte root ce qui est très déconseillé car on peu tout casser très facilement, je rappelle ce que j’ai déjà dit : root = dieu.

On va mettre tout ça en Français. Sur mon installation Debian il y a un bug avec la configuration des langues (ce qu’on appelle Locales) on va y remédier en même temps. Par défaut il devrait y avoir la langue anglaise en_US.UTF-8 et on va passer en Français fr_FR.UTF-8. On commence par générer les fichiers des deux langues :

locale-gen en_US.UTF-8
locale-gen fr_FR.UTF-8

Puis on reconfigure le tout :

dpkg-reconfigure locales

On choisi nos deux langues dans la liste proposée, OK, puis on demande d’utiliser le Français. (Perso je préfère en Anglais.)

  • TIPS : Dans les fenêtres de configuration sur fond bleu on utilise la touche de tabulation du clavier pour aller d’un menu à l’autre, et la barre d’espace pour sélectionner un item dans une liste.

Voila normalement on ne devrait plus avoir de message d’erreur comme ci-dessous :
fix_locales.png

On en profite pour mettre notre serveur sur le bon fuseau horaire, Europe, Paris pour moi :

dpkg-reconfigure tzdata

Maintenant on met un peu de couleur sur cette console bien sombre, même si ça ne sert pas à grand chose, ça a le mérite de nous entrainer et de nous familiariser avec certains mots. Pour cela on modifie la configuration bash du compte root :

nano ~/.bashrc

On dé-commente les lignes comme suit, ce qui aura pour effet d’ajouter un peu de couleur :
edit_bashrc_color.png
On enregistre puis on recharge cette configuration :

. ~/.bashrc
  • TIPS : Ce fichier commence par un point, c’est un fichier caché.

On test avec un petit listing du contenu d’un répertoire :
ls_with_colors.png

Et si on changeait le nom de la machine ? Chez OVH par défaut elle porte le doux nom de vpsxxxxx, j’ai envie de l’appeler scriboxWeb (j’appellerai la machine dédié à MySQL scriboxSql. Pour cela on modifie le fichier hostname qui devrait contenir une seule ligne qui est le nom de la machine qu’on remplace par un joli nom :

nano /etc/hostname

D’autres fichiers peuvent contenir des références à ce nom mais comme on commence l’installation du serveur, le seule dont on s’inquiétera est le suivant :

nano /etc/hosts

On modifie le nom court :
change_server_name.png
Pour recevoir de jolis mél de la part de root plus tard on va changer son nom dans le fichier des utilisateurs :

nano /etc/passwd

Il faut modifier la première ligne en replacçant la deuxiéme occurence de root par le nom qu’on veut voir apparaitre en expéditeur des mél root :

root:x:0:0:scribox:/root:/bin/bash

Pour que tout soit pris en compte et vérifier qu’on a pas tout cassé, on redémarre le système :

reboot

Au suivant

Voila on s’est bien amusé pour cette séance, dans le prochain billet on va voir comment sécuriser un peu notre accès à la console.

Sources

Sécuriser un peu SSH

Dans notre configuration d’un serveur Debian, après avoir fait joujou avec la console, on va commencer les choses sérieuses en apportant de petites modifications à notre connexion SSH.

Créer un compte

Comme déjà dit, il est déconseillé d’utiliser le compte root pour diverses raisons, on créé alors un nouvel utilisateur et son mot de passe :

adduser jcdenis

On renseigne ou non les informations demandées, cela n’a pas d’importance :
create_user.png
Heu, jcdenis, c’est moi, pour l’exemple, alors mettez un autre login de préférence un peu bizarre, ou donnez moi le mot de passe de vote machine !
Il faut également donner les droits super utilisateur (ou su) à notre nouveau compte, pour cela on modifie le fichier des groupes :

nano /etc/group

On ajoute le nouveau compte à la ligne sudo :
add_to_sudo.png
Dorénavant on utilisera ce nouveau compte pour se connecter à la machine.

Modifier SSH

On va interdire de se connecter avec le compte root ce qui sera notre tout premier pas dans la sécurisation de notre serveur et on en profitera pour changer le port de connexion, notre deuxième pas dans la sécurisation. Pour cela on modifie le fichier de configuration de SSH :

nano /etc/ssh/sshd_config

edit_ssh_conf.png
Mettre un port au hasard comme par exemple 2425, 2030, et retenez le. Enfin pas trop au hasard non plus, certains sont déjà utilisés !
On pourrait également envoyer un petit mél à chaque fois que quelqu’un se connecte au compte root, on va d’abords ajouter notre adresse mél de redirection :

nano /etc/aliases

add_alias.png
On prend en compte la modification avec la commande :

newaliases

Puis on ajoute la commande d’envoi de mél à la fin du bash root :

nano /root/.bashrc

Ce qui donne un fichier bash dans ce style :

# ~/.bashrc: executed by bash(1) for non-login shells.

export LS_OPTIONS=’–colors=auto’
eval “`dircolors`”
alias ls=’ls $LS_OPTIONS’
alias ll=’ls $LS_OPTIONS -l’
alias l=’ls $LS_OPTIONS -lA’

echo “Acces au Shell Root :” `date` `who` | mail -s “`hostname` – Connexion shell” root — -f noreply@.org

On relance le bash :

. ~/.bashrc

On fera de même pour notre nouvel utilisateur :

nano /home/jcdenis/.bashrc

Test

Une fois modifié, on redémarre SSH :

/etc/init.d/ssh restart

On ouvre une nouvelle console sans oublier qu’on a changé de port de connexion, on teste qu’on ne peut plus se connecter directement avec l’utilisateur root, mais qu’on peut toujours avec notre nouveau compte et qu’on peut également utiliser la commande su suivi du mot de passe root :
login_as_root.png

On note au passage qu’on n’a rien configuré ou installé pour envoyer les mails, sendmail est déjà installé et pour ce qu’on veut faire de notre serveur il est inutile de chercher plus compliqué.

Au suivant

Tout à l’air de fonctionner, on va pouvoir passer à la phase suivante dans un prochain billet.