SFTPGo - Restriction des accès par dossiers

SFTPGo - Restriction des accès par dossiers

Problème

Si le root directory est accessible en écriture, l'utilisateur peut créer des dossiers hors des virtual folders.

Solution

1. Root directory

• Définir un dossier vide (ex: /srv/sftpgo-homes/ad64)
• Appliquer :

 chmod 555 /srv/sftpgo-homes/ad64

2. Virtual folders

Mapper uniquement les dossiers autorisés :

• pleade → /var/data/ad64-data/data/pleade
• projets → /var/data/ad64-data/data/projets

3. ACL

Permissions globales :

• list
• download

Permissions spécifiques :

• /pleade → upload, create_dirs, delete, etc.
• /projets → upload, create_dirs, delete, etc.

Permissions racine :

• / → list uniquement

Résultat

• Impossible de créer des dossiers hors des virtual folders
• Accès strictement limité aux chemins définis

SFTPGo – Règles et bonnes pratiques

Structure recommandée

• Root directory utilisateur :

 /var/sftpgo-homes/<user>

• Données réelles :

 /var/data/<client>-data/data/

• Utiliser uniquement des "Virtual folders" pour exposer les données :

 /pleade  → <client>-pleade
 /projets → <client>-projects

Sécurité des répertoires

• Interdire toute écriture à la racine :

 chmod 555 /var/sftpgo-homes/<user>

• Objectif :

 empêcher la création de dossiers hors périmètre (ex: /toto)

Permissions (ACL)

• Ne jamais utiliser '*' sur '/'
• Configuration recommandée :

 /          → list, download
 /pleade    → *
 /projets   → *

• Risque sinon :

 création de fichiers/dossiers hors des répertoires prévus

Restrictions horaires

• ATTENTION :

 une restriction horaire invalide provoque un "invalid credentials"

• Exemple dangereux :

 Sunday 00:00 → 23:59

• Bonne pratique :

 - supprimer les restrictions si inutiles
 - ou définir tous les jours explicitement

Mots de passe

• "Require password change" :

 fonctionne uniquement via WebClient
 → ne pas activer pour des utilisateurs SFTP (FileZilla)

• Si problème :

 utiliser :
 sftpgo resetpwd --admin <admin>

Debug authentification

• Vérifier dans la base :

 sqlite3 /var/lib/sftpgo/sftpgo.db
 select username,status from users;

• status = 1 → OK

• Causes fréquentes d’échec :

 - restriction horaire
 - ACL incorrectes
 - IP non autorisée
 - mauvais protocole (Web vs SFTP)

SFTPGo – Configuration, sécurisation et sauvegardes

1. Objectif

Mettre en place une configuration homogène et sécurisée des comptes SFTPGo, basée sur un modèle validé (ex : utilisateur ad64), et automatiser les sauvegardes.

2. Architecture retenue

• 1 utilisateur SFTPGo par personne (pas de compte partagé)
• Utilisation de Virtual folders
• Répertoire racine non modifiable
• Permissions fines par dossier
• Désactivation des fonctionnalités sensibles non utiles aux clients

3. Configuration utilisateur (modèle ad64)

3.1 Répertoire racine

Root directory = /var/sftpgo-homes/ad64

Permissions système :

chmod 555 /var/sftpgo-homes/ad64

But :

• empêcher la création de dossiers hors périmètre

3.2 Virtual folders

Exemple :

• /pleade → ad64-pleade
• /projets → ad64-projets

3.3 ACL globales

Au niveau racine :

permissions = ["/": ["list"]]

But :

• autoriser uniquement la navigation à la racine
• empêcher le download global

3.4 ACL par dossier

/pleade

Permissions :

• list
• upload
• overwrite
• create_dirs
• rename
• rename_files
• rename_dirs
• delete
• delete_files
• delete_dirs
• copy

But :

• dépôt et gestion possibles
• download interdit par défaut

/projets

Permissions :

• list
• download
• upload
• overwrite
• create_dirs
• rename
• rename_files
• rename_dirs
• delete
• delete_files
• delete_dirs
• copy

But :

• répertoire d’échange complet

3.5 ACL fines par sous-répertoire

Exemple de logique retenue :

• /pleade/*/alto
• /pleade/*/cdc
• /pleade/*/csv
• /pleade/*/eac
• /pleade/*/ead
• /pleade/*/excell
• /pleade/*/mets
• /pleade/*/nc
• /pleade/*/pdf
• /pleade/*/unimarc
• /pleade/*/xml

But :

• autoriser le download uniquement pour certains types de dossiers
• éviter un download massif non souhaité sur d’autres répertoires comme les images

3.6 Fonctionnalités Web désactivées

Dans Web client / REST API :

• password-reset-disabled
• publickey-change-disabled
• tls-cert-change-disabled
• api-key-auth-change-disabled
• info-change-disabled
• shares-disabled
• shares-without-password-disabled

But :

• éviter les partages publics
• éviter les modifications avancées côté client
• garder une interface simple et contrôlée

3.7 2FA

Choix retenu :

• 2FA non activé par défaut
• activation au cas par cas selon le client et le mode d’accès

Remarque :

• FileZilla gratuit ne gère pas correctement le 2FA en SFTP
• le 2FA est donc surtout adapté au WebClient, ou à des clients compatibles

4. Vérifications utiles

4.1 Vérifier les utilisateurs

sqlite3 /var/lib/sftpgo/sftpgo.db
select username,status from users;

4.2 Vérifier la structure SQL

sqlite3 /var/lib/sftpgo/sftpgo.db
.schema users

4.3 Sauvegarde manuelle rapide de la base

cp /var/lib/sftpgo/sftpgo.db /var/lib/sftpgo/sftpgo.db.bak_$(date +%F_%H-%M)

4.4 Sauvegarde plus propre avec arrêt du service

systemctl stop sftpgo
cp /var/lib/sftpgo/sftpgo.db /var/lib/sftpgo/sftpgo.db.bak_$(date +%F_%H-%M)
systemctl start sftpgo

4.5 Dump SQL

sqlite3 /var/lib/sftpgo/sftpgo.db ".dump" > /root/sftpgo_dump_$(date +%F_%H-%M).sql

5. Uniformisation des utilisateurs

5.1 Principe

• prendre ad64 comme modèle
• appliquer les mêmes ACL aux autres utilisateurs
• ne pas modifier :
  • le quota
  • le nom d’utilisateur
  • le mot de passe
  • les virtual folders

5.2 Méthode retenue

• export JSON
• modification du JSON
• import avec mise à jour

5.3 Effet recherché

• tous les clients ont la même base de sécurité
• moins d’erreurs
• gestion plus simple
• future création de groupes facilitée

6. Sauvegardes automatiques

6.1 Script

Fichier :

/usr/local/sbin/backup_sftpgo.sh

Fonctions :

• backup quotidien de la base
• dump SQL quotidien
• rotation sur 7 jours
• copie hebdomadaire le dimanche
• backup manuel possible avant import JSON ou changement massif

6.2 Exécution manuelle

/usr/local/sbin/backup_sftpgo.sh daily

Backup manuel :

/usr/local/sbin/backup_sftpgo.sh manual

6.3 Cron

crontab -e

Exemple :

15 2 * * * /usr/local/sbin/backup_sftpgo.sh daily >> /var/log/backup_sftpgo.log 2>&1

6.4 Vérification

find /var/backups/sftpgo -maxdepth 2 -type f | sort

7. Rotation des logs

7.1 Fichier logrotate

Fichier :

/etc/logrotate.d/sftpgo-local

Contenu :

/var/log/backup_sftpgo.log
/var/log/sftpgo*.log
/var/log/fail2ban.log {
    su root adm
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root adm
    sharedscripts
    postrotate
        systemctl reload rsyslog >/dev/null 2>&1 || true
    endscript
}

7.2 Test

logrotate -d /etc/logrotate.d/sftpgo-local

Test forcé :

logrotate -f /etc/logrotate.d/sftpgo-local

8. Journal systemd

8.1 Vérification

journalctl --disk-usage

8.2 Réglage

Fichier :

/etc/systemd/journald.conf

Exemple :

SystemMaxUse=500M
SystemMaxFileSize=50M
MaxRetentionSec=30day

Puis :

systemctl restart systemd-journald

9. Bonnes pratiques

• toujours faire un backup avant import JSON
• ne pas modifier SQLite directement sauf nécessité
• tester d’abord sur un utilisateur modèle
• éviter les comptes partagés
• privilégier des utilisateurs nominatifs
• préparer ensuite des groupes pour industrialiser la configuration

10. Évolutions prévues

• création de groupes par client
• template de configuration standard
• éventuel script de provisioning
• différenciation entre comptes humains et comptes techniques

Réseau / sécurité

• Restreindre l’accès WebAdmin (port 9090) via UFW :

 ufw allow from <IP> to any port 9090

• Ne jamais exposer WebAdmin publiquement

Pièges connus

• Bouton "Add folder" visible même si interdit → normal
• Message "invalid credentials" trompeur
• Droits '*' mal placés = fuite de périmètre
• Root writable = chaos assuré

Bonnes pratiques générales

• Toujours tester avec un utilisateur client réel
• Vérifier :

 - création de fichiers
 - impossibilité de sortir du périmètre
 - quotas visibles

• Documenter chaque règle ajoutée