Archives de catégorie : Serveur web

MySQL

Quoiqu’on dise sur le rachat de MySQL par Oracle, cela reste un des systèmes de gestion de bases de données les plus courants dans le monde web.

Sécurisation de l’installation

Il faut lancer l’utilitaire installé par défaut, qui permet déjà de corriger certains points.

sudo mysql_secure_installation

A la 1ère question, sur le plugin des mots de passe, vous pouvez l’activer ou pas : ce plugin sert à vérifier que les mots de passe utilisés sont suffisamment fort. Utile en production, cela peut apporter des contraintes trop importantes en développement. Et rien ne vous empêche de vous forcer à mettre des mots de passe forts par vous-même.
Ensuite il vous demandera un mot de passe pour root. A renseigner avec un mot de passe fort impérativement.
Puis il demandera la suppression des utilisateurs anonymes, à approuver également.
Désactivation d’accès distant pour root : sage précaution encore, à accepter.
Dernière chose : suppression des bases de test, évitant ainsi un accès trop facile au SGBD.

Avant de terminer, dites oui au rechargement des privilèges (qui ne seront pas effectifs tout de suite, sinon).

Sauvegarde

Pour réaliser la sauvegarde d’une base de données MySQL, une commande peut suffire :

mysqldump table -u user -p >> fichier_destination

Attention : cela vous demandera le mot de passe de l’utilisateur correspondant, de façon interactive.

Ossec

OSSEC est un HIDS de niveau système, qui s’installe sur quasiment n’importe quelle distribution Linux du moment qu’un administrateur dispose d’un compilateur C sur la machine adéquate. Cet HIDS peut s’installer seul (il ne vérifie que ce qui se passe sur la machine) ou en tant que serveur/agent (c’est-à-dire qu’on l’installe sur une machine centrale ou serveur, qui contrôle tout un réseau de machines sur lesquelles on installe des agents ossec). Je décrirai ici l’installation dite « locale », à savoir qu’on ne surveille que son propre serveur.

Pré-requis

Il est possible que certains éléments ne soient pas installés sur le système de base. Pour Ubuntu 16 (LTS), il faut :

apt install libpcre2-dev (à compléter)

Procédure

D’abord en téléchargeant la dernière version, par exemple dans votre répertoire /home (ou tout répertoire sur lequel vous avez un droit root, car il est impértif d’installer cet utilitaire en tant qu’administrateur du système).

$ git clone https://github.com/ossec/ossec-hids 
$ cd ossec-hids 
$ ./install.sh

Vérifiez qu’il s’agit bien de la dernière version. Et sinon c’est tout ce qu’il y a à faire, à la réserve près de répondre aux questions de l’installateur. Cela suffira pour un serveur web isolé. Il est possible d’avoir aussi un serveur surveillant plusieurs autres (appelés agents)

Installation locale

Choisir le type d’installation et la langue

1- Choisir le type d'installation (local) 
... 
** Za instalaciju na srpskom, izaberi [sr]. 
** Türkçe kurulum için seçin [tr]. 
(en/br/cn/de/el/es/fr/it/jp/pl/ru/sr/tr) [en]: fr 
1- Quel type d'installation voulez-vous (serveur, agent, local ou aide) ? local 
- Installation en local choisie.

Définition de l’environnement d’installation

2- Définition de l'environnement d'installation. 
- Choisissez votre répertoire d'installation de OSSEC HIDS 
[/var/ossec]: (garder la valeur par défaut comme indiqué) 
- L'installation sera faite sur /var/ossec .

Configuration de OSSEC HIDS

3- Configuration de OSSEC HIDS. 
3.1- Voulez-vous une alerte par email ? (o/n) [o]: n 
--- Alerte par email désactivée. 
3.2- Voulez-vous démarrer le démon de vérification d'intégrité ? (o/n) [o]: o 
- Lancement de syscheck (démon de vérification d'intégrité). 
3.3- Voulez-vous démarrer le moteur de détection de rootkit ? (o/n) [o]: o 
- Lancement de rootcheck (détection de rootkit). 
3.4- La réponse active vous permet d’exécuter des 
commandes spécifiques en fonction d'évènement. Par exemple, 
vous pouvez bloquer une adresse IP ou interdire l'accès à 
un utilisateur spécifique. 
Plus d'information sur : http://www.ossec.net/en/manual.html#active-response 
- voulez-vous démarrer la réponse active ? (o/n) [o]: o 
- Réponse active activée. 
- Par défaut, nous pouvons activer le contrôle d'hôte 
et le pare-feu (firewall-drop). Le premier ajoute 
un hôte dans /etc/hosts.deny et le second bloquera 
l'hôte dans iptables (sous linux) ou dans ipfilter 
(sous Solaris, FreeBSD ou NetSBD). 
- Ils peuvent aussi être utilisés pour arrêter les scans 
en force brute de SSHD, les scans de ports ou d'autres 
formes d'attaques. Vous pouvez aussi les bloquer par 
rapport à des évènements snort, par exemple. 
- Voulez-vous activer la réponse pare-feu (firewall-drop) ? (o/n) [o]: o 
- pare-feu (firewall-drop) activé (local) pour les levels >= 6 
- liste blanche (white list) par défaut pour la réponse active : 
- 212.27.54.252 
- 212.27.53.252 
- Voulez-vous d'autres adresses IP dans votre liste (white list) ? (o/n)? [n]: o 
- IPs (séparées par des espaces) : votre-ip

Puis lancez ossec via la commande indiquée en résultat /var/ossec/bin/ossec-control start, le programme sera également lancé à chaque redémarrage du serveur.

Une précaution importante à prendre

Okay, ossec est simple à installer, mais si vous voules qu’il serve à quelque chose, il faut impérativement :

Autoriser la réponse active lors de l’installation (ou du paramétrage) : ossec bloquera (temporairement) les adresses IP causant des problèmes.
Mettre les bons répertoires de logs dans le fichier de configuration.

Cet outil se base sur les logs pour trouver des anomalies : il faut donc inclure a minima les logs du systèmes et les logs de vos serveurs web !

Shorewall

Shorewall est un excellent pare-feu simple à configurer. Pour être plus précis, cet outil permet de configurer facilement des règles iptables.

Installation

Linux général

Télécharger le source, et lancer une installation classique :

$ wget http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.8/shorewall-4.4.8.2.tgz 
$ tar –xvf shore* 
$ ./install.sh

Fedora, Red Hat et CentOS

Encore une fois, des distributions récentes peuvent proposer shorewall. L’avantage est que la mise-à-jour est automatique, l’inconvénient est que vous n’avez pas toujours la dernière vesion. Dans ce cas, l’installation est cependant beaucoup plus simple :

yum install shorewall

Il ne reste plus qu’à configurer Shorewall, en comprenant un peu ce que l’on fait…

Ubuntu et Debian

C’est à peu près aussi simple que sur Red Hat like :

apt-get install shorewall

Par contre attention, pour que Shorewall démarre automatiquement, n’oubliez pas de mettre de modifier le fichier /etc/default/shorewall et de mettre startup=1.

Protections Linux

Il faut aussi penser à autoriser shorewall avec AppArmor, SELinux, etc.
Pour AppArmor : http://doc.ubuntu-fr.org/apparmor.

Configuration en hôte simple

Définissez le fichier interfaces

#ZONE   INTERFACE       BROADCAST       OPTIONS 
net     vmbr0           detect          dhcp,routefilter,nosmurfs,logmartians,tcpflags 
dmz     venet0          detect          tcpflags,routeback

Définissez le fichier zones

#ZONE   TYPE            OPTIONS         IN                      OUT 
#                                       OPTIONS                 OPTIONS 
fw      firewall 
net     ipv4 
dmz     ipv4

Définissez le fichier policy

A noter : on peut abaisser le niveau de log.

#SOURCE     DEST        POLICY          LOG             LIMIT:  CONNLIMIT: 
#                                       LEVEL           BURST   MASK 
# 
# 
à revoir

Définissez le fichier rules

Pour commencer, on met les règles de base pour permettre la connexion, ici dans le cadre d’une machine Proxmox.

#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINAL        RATE            USER/   MARK    CONNLIMIT       TIME 
#                                                       PORT    PORT(S)         DEST            LIMIT           GROUP 
#SECTION ESTABLISHED 
#SECTION RELATED 
SECTION NEW 
#

Pour Plesk, ajouter :

ACCEPT          net             dmz:IP1,IP2,IP3...               udp     8443 
ACCEPT          net             dmz:IP1,IP2,IP3...               tcp     8443,8447

Pour CPanel, ajouter :

ACCEPT         net             dmz:IP1,IP2,IP3...               tcp     2077,2078,2082,2083,2086,2087,2089,2095,2096 
ACCEPT         net             dmz:IP1,IP2,IP3...               udp     2077,2078

Si vous utilisez un collecteur de logs (par exemple Ossec) :

ACCEPT          net             dmz:votre_ip               udp     514,1514

Quelques bugs et anomalies

Le bug Ubuntu 15.04 et suivants

Sur Ubuntu 15, shorewall semble ne pas démarrer. On peut considérer cela comme très gênant. Peu d’informations sont disponibles sur le web, à part un bug ouvert¹ chez Debian.
Une solution semble être l’installation d’un package supplémentaire, shorewall-init. Dans mon cas, ça a marché.

Problème de redémarrage

Il m’est arrivé d’installer shorewall, de le lancer, mais qu’après un reboot, rien ne démarre. J’avais trouvé la solution au fin fond d’un forum (launchpad), mais cela venait d’un problème dans la gestion du démarrage des services. Pour le résoudre :

 sudo systemctl enable /lib/systemd/system/shorewall.service

Mod security

mod_security est filtre (pare-feu) applicatif se présentant sous le forme d(un module que l’on peut ajouter à son serveur web Apache. Son rôle est de filtrer les requêtes bizarroïdes. Certaines distributions récentes (comme Fedora) l’intègrent et ce module peut donc être installé très facilement.

L’installation automatique convient parfaitement, mais si vous voulez avoir la toute dernière version ou si votre distribution ne la contient pas, j’ai aussi décrit la procédure manuelle.

Installation automatique

Sous Fedora 8, il suffit de taper, en mode root :

yum install mod_security

Et le toujours est joué… une fois que le serveur web aura redémarré (cf ci-dessous) :

apachectl restart

En général, les règles par défaut sont assez fines et évoluées, il n’y a pas à y toucher, sauf si cela bloque des fonctionnalités de votre site.

Si une règle vous bloque

C’est pas de chance, car il faudra alors désactiver une règle, ce qui potentiellement vous expose à une faille de sécurité. Bon, mais en pratique, il est rare qu’une règle soit cruciale à elle seule, et les autres vous permettront de conserver un niveau de sécurité acceptable. Si toutefois vous devez en désactiver plusieurs, il faudra alors se poser de sérieuses questions sur votre site, qui doit employer des techniques intrusives ou qui est conceptuellement mal sécurisé.

Comment le savoir ?

Faites un tour dans le répertoire /var/log/httpd et regardez le contenu des fichiers de logs de mod_security.

[root@host httpd]# tail -20 modsec_audit.log
GET / HTTP/1.1
Host: xx.xxx.xxx.xxx

--54705f53-F--
HTTP/1.1 400 Bad Request
Content-Length: 305
Connection: close
Content-Type: text/html; charset=iso-8859-1

--54705f53-H--
Message: Warning. Match of "rx ^OPTIONS$" against "REQUEST_METHOD" required. [id "960015"] [msg "Request Missing  an Accept Header"] [severity "CRITICAL"]
Message: Warning. Operator EQ match: 0. [id "960009"] [msg "Request Missing a User Agent Header"]    [severity "WARNING"]
Message: Access denied with code 400 (phase 2). Pattern match "^[\d\.]+$" at REQUEST_HEADERS:Host.   [id "960017"] [msg "Host header is a numeric IP address"] [severity "CRITICAL"]
Action: Intercepted (phase 2)
Stopwatch: 1211041326569321 1012 (293 703 -)
Producer: ModSecurity v2.1.7 (Apache 2.x)
Server: Apache/2.2.8 (Fedora)

--54705f53-Z--

On peut aussi avoir des infos dans /var/log/httpd/modsec_debug.log :

[root@ikobox httpd]# tail -6 modsec_debug.log
[17/May/2008:18:22:06 +0200] [91.121.138.106/sid#802cace0][rid#8064f0f8][/][2] Warning. Match of "rx ^OPTIONS$" against "REQUEST_METHOD" required. [id "960015"] [msg "Request Missing an Accept Header"] [severity "CRITICAL"]
[17/May/2008:18:22:06 +0200] [91.121.138.106/sid#802cace0][rid#8064f0f8][/][2] Warning. Operator EQ match: 0. [id "960009"] [msg "Request Missing a User Agent Header"] [severity "WARNING"]
[17/May/2008:18:22:06 +0200] [91.121.138.106/sid#802cace0][rid#8064f0f8][/][1] Access denied with code 400 (phase 2). Pattern match "^[\d\.]+$" at REQUEST_HEADERS:Host. [id "960017"] [msg "Host header is a numeric IP address"] [severity "CRITICAL"]
[17/May/2008:18:27:08 +0200] [91.121.138.106/sid#802cace0][rid#806440d0][/][2] Warning. Match of "rx ^OPTIONS$" against "REQUEST_METHOD" required. [id "960015"] [msg "Request Missing an Accept Header"] [severity "CRITICAL"]
[17/May/2008:18:27:08 +0200] [91.121.138.106/sid#802cace0][rid#806440d0][/][2] Warning. Operator EQ match: 0. [id "960009"] [msg "Request Missing a User Agent Header"] [severity "WARNING"]
[17/May/2008:18:27:08 +0200] [91.121.138.106/sid#802cace0][rid#806440d0][/][1] Access denied with code 400 (phase 2). Pattern match "^[\d\.]+$" at REQUEST_HEADERS:Host. [id "960017"] [msg "Host header is a numeric IP address"] [severity "CRITICAL"]

On voit que la règle 960017 est remplie, ce qui correspond à une type d’attaque. Après, à vous de voir s’il faut la désactiver.

Comment le corriger ?

Les règles sont dans /etc/httpd/modsecurity.d dans l’installation sous Fedora 8.

[root@ikobox conf.d]# cd /etc/httpd/modsecurity.d
[root@ikobox modsecurity.d]# grep '960017' *
modsecurity_crs_21_protocol_anomalies.conf:SecRule REQUEST_HEADERS:Host "^[d.]+$" "deny,log,auditlog,status:400,msg:'Host header is a numeric IP address', severity:'2',id:'960017'"

Liens externes

Site officiel de mod-security

Chkrootkit

chkrootkit est un programme dont le but est de détecter la contamination d’une machine par un rootkit sur des machines de type Linux.

DNS

Le protocole DNS permet de connaître l’adresse réelle d’un serveur web. Plus précisément cela transforme le nom de domaine inclus dans une URL (adresse symbolique du genre https://secu.si) en adresse technique (adresse IP).

Pour cela, de très nombreux serveurs se répartissent la tâche sur toute la planète web. Pour des raisons d’efficacité, nous nous retrouvons souvent connectés directement à un serveur géré par notre fournisseur d’accès internet. Rien de bien fameux, sauf que les fournisseurs d’accès gardent souvent des traces, pour leur usage propre ou parce qu’on leur demande¹.

Vie privée ?

A priori pas d’influence de l’utilisation d’un service de DNS sur sa vie privé. Et pourtant…

Transparence et traçabilité

Nous laissons des traces de notre activité dès qu’on sollicite ces serveurs DNS classiques. Même en navigation privée, le serveur DNS sait sur quels sites nous surfons. Il peut aussi interdire la navigation sur certains sites qui lui sont désignés par le pouvoir public.

Autre problème : il existe plusieurs types d’attaques sur la résolution de nom de domaine via DNS. D’où l’intérêt d’utiliser un service DNS à la fois respectueux de la vie privée mais également sécurisé. On peut par exemple savoir ce que vous faites, même si le serveur ne garde pas de traces d’activité, en écoutant les requêtes DNS circulant de façon non sécurisée, en clair.

DNSSEC

Les différentes options

Le serveur FAI

L’avantage premier d’utiliser le serveur du FAI est de rester dans la légalité (et donc dans la censure dans certains pays), ainsi que la simplicité d’utilisation vu que c’est le paramétrage par défaut à l’installation de votre ligne d’accès internet.

Les services dédiés

Tout dépend ensuite de la confiance que vous accordez au fournisseur que vous allez sélectionner. Il s’agit parfois d’un moindre mal : on accepte les défauts et contraintes des fournisseurs pour pouvoir contourner des blocages de type censure.

Google

Google n’est pas forcément votre ami. Oui, il vous aide à trouver presque tout ce que vous voulez, mais quand il propose des services périphériques, il y a souvent anguille sous roche. Certes il est très rapide, il y a des gens qui ont essayé, et je suppose qu’ils ont eu de problèmes. Je suppose, soyons honnête, je n’ai pas entendu de cas suspect suite à l’utilisation de Google DNS, mais si techniquement il est extrêmement rapide (c’est vrai), il appartient à Google dont le principal revenu est la publicité, et donc son fond de commerce² est basé sur le ciblage des utilisateurs. Méfiance, donc.

Les IP du Google DNS sont :

8.8.8.8
8.8.4.4

Des IP simples, on n’en attendait pas moins d’un géant du web.

Quad9

Cette solution est un peu particulière, car il existe deux versions :

9.9.9.9 ou 2620:fe::fe qui utilise DNSSEC et qui renvoie une liste filtrée et épurée des IP dangereuses ou malveillantes, comme celles utilisées par des botnets ;
9.9.9.10 ou 2620:fe::10 qui ne filtre rien, mais qui ne fait pas de DNSSEC contrairement à 9.9.9.9.

Proposée au départ par IBM via X-Force³, elle est gérée par une association à but non lucratif. Pas mal non plus pour le choix des adresses IP.

OpenDNS

Je ne connais pas bien OpenDNS, mais le service a connu des oppositions liées à l’usage publicitaire ayant été fait des données d’utilisation. Aujourd’hui cela appartient à Cisco, la publicité a été arrêtée⁴, mais là encore la méfiance est de mise.

CloudFlare

CloudFlare est connu pour ses solutions industrielles, notamment anti-DDoS, ayant servi dans différents événements et attaques. Sans être philanthrope, on sait que cette société tient à garder une image propre et elle est plutôt encline à défendre la veuve, l’orphelin et l’internaute.

En avril 2018, CloudFlare a lancé un service de DNS gratuit et sécurisé sur l’adresse IP 1.1.1.1 (chapeau pour avoir mis la main sur cette adresse⁵).

SPOF

CloudFlare ou Quad9 sont bien placés pour emporter la mise et protéger notre vie privée. Attention toutefois au paramétrage de vos serveurs DNS : une bonne idée pourrait être de panacher les fournisseurs pour éviter le risque de déni de service, car on tombe dans le risque du SPOF si on ne choisit qu’un seul fournisseur. Par contre il faut avoir bien confiance en les deux que vous retiendrez.

Références

SQL Express (Sauvegarde)

SQL Express

Tout d’abord il faut un script SQL du genre :

BACKUP DATABASE jean TO DISK=N'G:SQLMaBase.bak'GO

On peut faire un peu plus complexe, avec cet exemple généré par SQL Exress :

BACKUP DATABASE [base] TO  DISK = N'C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLBackupbase.bak' WITH NOFORMAT, NOINIT,  NAME = N'base-Complète Base de données Sauvegarde', SKIP, NOREWIND, NOUNLOAD,  STATS = 10GO

Ensuite il faut automatiser ce script. Pour lancer un script SQL sous Windows, il faut utilisre osql :

sqlcmd -S nom_instance -E -i requete.sql -o fichier_sortie.txt

Par exemple :

@echo off 
: copie 
sqlcmd -S .SQLEXPRESS -E -i svg_base.sql -o svg.log 
rename "C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLBackupbase.bak" svg_%date:~6,4%%date:~3,2%%date:~0,2%.bak 
: supp 
if not exist "C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLBackupbase.bak" goto fin 
del "C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLBackupbase.bak" 
: fin

Plus d’infos :

http://fadace.developpez.com/mssql/sauve/
http://www.asp-php.net/tutorial/sql-server/sauvegarder-bases-de-donnees-sql-express.php?page=1

Plesk (Sauvegarde)

Backup/Restore sur Plesk.
Les utilitaires permettant les sauvegardes/restauration sont dans /usr/local/psa/bin/pleskbackup.

Sauvegarde

C’est simple, une seule commande pour tout sauvegarder :

./pleskbackup all

Restauration

Je n’indique ici que la restauration complète. Il est possible de ne restaurer qu’une partie de la machine (domaine, client, etc). Il y a deux étapes, une première où est créé un fichier indiquant ce qu’il y a à restaurer (map file name, qui est donc un nouveau fichier créé par pleskrestore), puis la restauration elle-même.

./pleskrestore --create-map   -map

./pleskrestore --restore  -map  -level all

Message d’accueil

Lorsqu’un utilisateur se connecte à un système dont vous avez la responsabilité, il est de bon ton de le saluer, mais il est également utile de lui rappeler qu’il n’est pas dans un domaine public et qu’il doit avoir été autorisé à venir. Pour cela, un petit rappel dans le message d’accueil peut être bienvenu. S’il n’empêchera pas un utilisateur mal intentionné de poursuivre, il évitera les maintiens accidentels de connexion, et il aura aussi son utilité en cas de poursuites judiciaires, car le pirate ne pourra pas dire qu’il n’était pas prévenu.

Pour cela, il suffit d’éditer un fichier /etc/motd (si vous avez la main sur celui-ci) et y mettre son commentaire, de manière suffisamment claire pour qu’il n’y ait pas d’ambiguïté… En voici un (ancien) exemple que j’ai utilisé :

##    ##  ######     ###         ######   #######  ##     ##
###   ## ##    ##   ## ##       ##    ## ##     ## ###   ###
####  ## ##        ##   ##      ##       ##     ## #### ####
## ## ##  ######  ##     ##     ##       ##     ## ## ### ##
##  ####       ## #########     ##       ##     ## ##     ##
##   ### ##    ## ##     ## ### ##    ## ##     ## ##     ##
##    ##  ######  ##     ## ###  ######   #######  ##     ##
 

This computer system is for authorized users only. All activity
is logged and regulary checked by systems personal. Individuals
using this system without authority or in excess of their authority
are subject to having all their services revoked. Any illegal
services run by user or attempts to take down this server or its
services will be reported to local law enforcement, and said user
will be punished to the full extent of the law. Anyone using this
system consents to these terms.

L’usage de ce serveur est réservé aux personnes autorisées. Toute
activité est journalisée et régulièrement vérifiée par le système.
Toute personne utilisant ce serveur sans autorisation ou en outre-
passant ses droits risque la fermeture des services concernés.
Toute activité illégale ou tentative de corruption ou d’intrusion
du serveur sera passible de poursuites dans la juridiction compétente.
Tout utilisateur de ce système informatique accepte ces
conditions d’utilisation.

=================================================================================
Contact : acebox_com@yahoo.fr ou admin@ace-box.com
=================================================================================

Serveur : acebox
IP      : 88.191.32.128
Add MAC : 00:40:63:e5:c3:de
OS      : Fedora Core release 4 (Stentz) installe le 2006-07-04 12:02:18

Pour sécuriser encore plus la connexion, vous pouvez également vous envoyer un e-mail d’alerte.

Plesk (Maintenance)

Sauvegarde et restauration

Sauvegarde

Je conseille de sauvegarder l’ensemble des sites et des éléments qui sont gérés par Plesk. Pour cela, la procédure est très simple puisqu’une seule ligne de commande suffit :

./pleskbackup all <backup file name>

Cet éxecutable se trouve dans le répertoire principal de Plesk, généralement /usr/local/psa/bin/pleskbackup.

Restauration

C’est un peu plus compliqué. Il faut d’abord créer un fichier « map » qui contiendra la liste des éléments à restaurer. Attention, car c’est indispensable et souvent ça prend du temps.

./pleskrestore --create-map  <backup file name> -map <map file name>

Ensuite, on demande de restaurer le fichier de backup, en utilisant ce qu’il y a dans ce fichier « map ». On peut modifier à la main ce fichier ; on peut également changer le niveau de restauration (via le paramètre -level, qui peut prendre plusieurs valeurs comme domain, client, etc).

./pleskrestore --restore  <backup file name> -map <map file name> -level all

Vérifier le système de quota

Pour pouvoir mettre en œuvre le système de gestion des quotas de disque par utilisateur, il peut être nécessaire de modifier les paramètres du système de fichiers.

Activez les quotas par système de fichiers en modifiant /etc/fstab qui doit contenir LABEL=/var /var ext3 defaults,usrquota,grpquota 1 2 pour le file system sur lequel sera stocké les fichiers des utilisateurs (clients) de Plesk (qui est par défaut /var).
Remontez le(s) système(s) de fichiers (par un reboot)

Tout ceci se fait normalement automatiquement lors de l’installation de Plesk, mais cela ne coûte rien de vérifier.