Sécuriser votre plateforme ORKA

01

Comprendre ce que nous allons protéger

ORKA s’appuie sur plusieurs composants qui communiquent entre eux. Chacun remplit un rôle précis et chacun peut devenir une porte d’entrée s’il est exposé ou mal configuré.

02

Mettre le serveur à jour

Les mises à jour corrigent des défauts de fonctionnement, mais aussi des vulnérabilités connues. Un serveur non maintenu devient progressivement plus facile à attaquer, même si sa configuration initiale était correcte.

Rechercher et installer les mises à jour

$ sudo apt update
$ sudo apt upgrade -y

Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done

0 upgraded, 0 newly installed,
0 to remove and 0 not upgraded.

Vérifier si un redémarrage est nécessaire

$ test -f /var/run/reboot-required \
  && cat /var/run/reboot-required \
  || echo "Aucun redémarrage requis"

03

Créer un compte d’administration dédié

Le compte root dispose de tous les droits sur le serveur. L’utiliser quotidiennement augmente le risque d’erreur : une commande mal saisie peut modifier ou supprimer n’importe quel fichier.

Créer l’utilisateur

$ sudo adduser orkaadmin
$ sudo usermod -aG sudo orkaadmin

Vérifier l’appartenance au groupe sudo

$ groups orkaadmin

orkaadmin : orkaadmin sudo

04

Sécuriser l’accès SSH

SSH est la porte d’administration du serveur. Il doit rester accessible aux personnes autorisées, tout en résistant aux tentatives de connexion automatisées qui parcourent Internet en permanence.

Modifier la configuration SSH

# Interdire la connexion directe du compte root
PermitRootLogin no

# Conserver le port 22 ou choisir un autre port
Port 2222

# Limiter le nombre de tentatives
MaxAuthTries 5

# Désactiver les connexions sans mot de passe vide
PermitEmptyPasswords no

Vérifier la syntaxe avant redémarrage

$ sudo sshd -t

Si la commande ne retourne aucun message, la syntaxe est valide.

Redémarrer SSH

$ sudo systemctl restart ssh
$ sudo systemctl status ssh --no-pager

● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded
     Active: active (running)

Tester une seconde connexion

$ ssh -p 2222 orkaadmin@adresse-du-serveur

05

Configurer le pare-feu

Un service peut fonctionner correctement tout en étant exposé inutilement sur le réseau. Le pare-feu applique une règle simple : tout ce qui n’est pas explicitement autorisé doit rester fermé.

Installer UFW

$ sudo apt install -y ufw

Définir les règles

$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing
$ sudo ufw allow 2222/tcp
$ sudo ufw allow 80/tcp
$ sudo ufw allow 443/tcp

Activer et vérifier le pare-feu

$ sudo ufw enable
$ sudo ufw status numbered

Status: active

[ 1] 2222/tcp                  ALLOW IN    Anywhere
[ 2] 80/tcp                    ALLOW IN    Anywhere
[ 3] 443/tcp                   ALLOW IN    Anywhere

06

Bloquer les attaques répétées avec Fail2Ban

Des robots essaient automatiquement des combinaisons de comptes et de mots de passe sur les serveurs accessibles depuis Internet. Fail2Ban observe les échecs et bloque temporairement les adresses trop insistantes.

Installer Fail2Ban

$ sudo apt install -y fail2ban

Configurer la protection SSH

[sshd]
enabled = true
port = 2222
logpath = %(sshd_log)s
maxretry = 5
findtime = 10m
bantime = 1h

Redémarrer et contrôler

$ sudo systemctl restart fail2ban
$ sudo fail2ban-client status sshd

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  `- Total failed: 0
`- Actions
   |- Currently banned: 0
   `- Total banned: 0

07

Activer HTTPS

Sans HTTPS, les identifiants, les sessions et les données échangées avec ORKA peuvent circuler sans chiffrement. Le certificat TLS permet au navigateur d’authentifier le serveur et de chiffrer les communications.

Installer Certbot

$ sudo apt install -y certbot python3-certbot-nginx

Générer le certificat

$ sudo certbot --nginx -d orka.mondomaine.fr

Successfully received certificate.
Certificate is saved at:
  /etc/letsencrypt/live/orka.mondomaine.fr/fullchain.pem

Deploying certificate
Successfully deployed certificate for orka.mondomaine.fr

Tester le renouvellement automatique

$ sudo certbot renew --dry-run

08

Durcir la configuration NGINX

NGINX constitue la première couche visible depuis le réseau. Quelques règles simples permettent de masquer des informations, de bloquer certains fichiers sensibles et de limiter les requêtes trop volumineuses.

Masquer la version de NGINX

http {
    server_tokens off;

    # autres paramètres...
}

Limiter la taille des fichiers téléversés

server {
    client_max_body_size 50M;

    # configuration ORKA...
}

La valeur doit rester cohérente avec la limite définie dans ORKA et dans PHP. Elle évite qu’un client envoie une requête démesurée au serveur.

Bloquer les fichiers cachés sensibles

location ~ /\.(?!well-known).* {
    deny all;
    access_log off;
    log_not_found off;
}

Vérifier et recharger NGINX

$ sudo nginx -t
$ sudo systemctl reload nginx

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

09

Vérifier les permissions ORKA

Le serveur Web doit pouvoir écrire uniquement dans les répertoires prévus à cet effet. Donner des droits trop larges à l’ensemble de l’application facilite les modifications accidentelles ou malveillantes.

Rechercher les fichiers ouverts à tous

$ sudo find /var/www/orka -type f -perm -0002 -print
$ sudo find /var/www/orka -type d -perm -0002 -print

Aucun résultat.

Réappliquer les droits recommandés

$ sudo chown -R orka:www-data /var/www/orka
$ sudo find /var/www/orka -type d -exec chmod 2755 {} \;
$ sudo find /var/www/orka -type f -exec chmod 0644 {} \;
$ sudo chmod -R 2775 /var/www/orka/backend/var

10

Protéger MariaDB

La base de données contient les informations fonctionnelles d’ORKA. Elle n’a généralement aucune raison d’être accessible directement depuis Internet.

Vérifier l’adresse d’écoute

$ sudo ss -lntp | grep 3306

LISTEN 0 80 127.0.0.1:3306 0.0.0.0:* users:(("mariadbd",pid=812,fd=19))

L’adresse 127.0.0.1 indique que MariaDB accepte uniquement les connexions provenant du serveur lui-même.

Exemple de configuration locale

[mysqld]
bind-address = 127.0.0.1

Redémarrer MariaDB

$ sudo systemctl restart mariadb
$ sudo systemctl status mariadb --no-pager

11

Contrôler les services exposés

Chaque service réseau constitue une possibilité d’accès supplémentaire. La meilleure règle consiste à ne conserver que ce qui est réellement utile.

Lister les ports en écoute

$ sudo ss -lntup

tcp LISTEN 0 511 0.0.0.0:80       nginx
tcp LISTEN 0 511 0.0.0.0:443      nginx
tcp LISTEN 0 128 0.0.0.0:2222     sshd
tcp LISTEN 0 80  127.0.0.1:3306   mariadbd

Lister les services actifs

$ sudo systemctl list-units \
  --type=service \
  --state=running

12

Surveiller les journaux

Une protection efficace ne consiste pas uniquement à bloquer. Elle doit aussi permettre de comprendre ce qui se passe sur le serveur. Les journaux constituent souvent le premier indice d’une erreur ou d’une tentative d’intrusion.

Commandes utiles

$ sudo tail -f /var/log/nginx/error.log
$ sudo journalctl -u php8.4-fpm -f
$ tail -f /var/www/orka/backend/var/log/prod.log
$ sudo fail2ban-client status sshd

13

Valider la sécurisation

Avant de considérer le serveur comme prêt pour la production, vérifiez que chaque mesure importante est réellement active.

14

Bonnes pratiques

15

Dépannage courant