Nous sommes une association et proposons pour d’autres assos, petites mairies, clubs séniors, etc. des clouds privés, avec sauvegardes auromatiques.
Nous débarquons parce que nos VPS sont sous CentOS 8 (et qu’il n’est plus libre fin 21) avec Nextcloud d’installer.
Nous avons décidé de remplacer par Debian (nous espérons avoir pris la bonne décision)
Je m’en occupe et normalement, je passe par SSH mais des fois, je passe par Filezilla en SFTP.
Attention, c’est tout nouveau et nous sommes loin d’être des pros.
Notre nouveau VPS (chez Hosteur) à un Debian 10 Buster simple.
C’est un VPS de test, donc pas d’inquiétude si ça plante.
Ce que j’ai déjà fait :
Mettre a jour debian OK
Création d’un nouvel utilisateur OK
Vérifier que iptable est installé OK
Changer le port d’écoute ssh OK
Garder les sessions SSH ouvertes plus longtemps OK
Installer fail2ban OK
Déjà, comment vérifier si fail2ban est correctement installé et comment le configurer proprement ?
Ensuite, avant d’installer Nextcloud, comment finir de sécuriser (s’il le faut) le VPS.
J’espère que je je n’arrive pas trop longtemps après la bataille, mais pour fail2ban, ça dépend de ce que tu veux protéger avec. Généralement je me contente de protéger ssh, avec les paramètres standards. Si tu as changé le port ssh, il faut adapter le fichier /etc/fail2ban/jail.conf en conséquence:
[sshd]
# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
port = ssh # changer ici par le numéro de port désiré
logpath = %(sshd_log)s
backend = %(sshd_backend)s
Puis systemctl restart fail2ban. Pour surveiller que ça marche bien, tu peux faire
root@serveur:~# fail2ban-client status
Status
|- Number of jail: 1
`- Jail list: sshd
et
root@serveur:~# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
| |- Currently failed: 1
| |- Total failed: 9878
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 1
|- Total banned: 798
`- Banned IP list: 35.242.136.58
Pour le reste, restreindre l’authentification des connexions ssh au compte root à la seule méthode ‹ clé publique › est aussi une bonne idée.
Ensuite, ça dépendra des autres logiciels choisis pour Nextcloud: le serveur web (apache ou nginx), et le SGBD (mysql ou postgresql) (et aussi php). Leur sécurisation est assez largement documentée, il me semble.
Alors soit le service est crashé au démarrage (ça peut être une erreur de syntaxe par exemple), vérifie avec systemctl status fail2ban et journalctl -u fail2ban.
Sinon il y a un couac dans la conf du fichier socket. Tu peux afficher le retour de systemctl cat fail2ban ?
Tu devrais avoir une ligne comme ça, dedans:
PIDFile=/var/run/fail2ban/fail2ban.pid
Il faut s’assurer que la valeur est la même que dans le fichier /etc/fail2ban/fail2ban.conf:
C’est donc la 1ère hypothèse. Apparemment la syntaxe de ton fichier /etc/fail2ban/jail.d/1nf02m4c0253845714.conf ne lui plaît pas (« file contains no section headers »)
On dirait d’ailleurs le début d’un fichier de conf d’un site apache (" <VirtualHost *:80>"), une erreur de copier/coller ?
Je suis allé vérifier, exact pour le fichier d’un site apache.
J’ai viré puis :
root@cloud-ciuvr1n7:~# systemctl restart fail2ban
root@cloud-ciuvr1n7:~# fail2ban-client status
Status
|- Number of jail: 1
`- Jail list: sshd
root@cloud-ciuvr1n7:~# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 0
|- Total banned: 0
`- Banned IP list:
