ajout de fail2ban et des configurations pour sshd et postifx-sasl
This commit is contained in:
parent
b3d583aa83
commit
c45f3a0357
|
|
@ -0,0 +1,10 @@
|
|||
# Fail2Ban filter for postfix authentication failures
|
||||
[INCLUDES]
|
||||
before = common.conf
|
||||
|
||||
[Definition]
|
||||
_daemon = postfix/smtpd
|
||||
#failregex = ^%(__prefix_line)swarning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(: [ A-Za-z0-9+/]*={0,2})?\s*$
|
||||
failregex = warning: .*\[<HOST>\]: SASL LOGIN authentication failed
|
||||
improper command pipelining after CONNECT from .*\[<HOST>\]:
|
||||
ignoreregex =
|
||||
|
|
@ -0,0 +1,128 @@
|
|||
[INCLUDES]
|
||||
|
||||
# Read common prefixes. If any customizations available -- read them from
|
||||
# common.local
|
||||
before = common.conf
|
||||
|
||||
[DEFAULT]
|
||||
|
||||
_daemon = sshd
|
||||
|
||||
# optional prefix (logged from several ssh versions) like "error: ", "error: PAM: " or "fatal: "
|
||||
__pref = (?:(?:error|fatal): (?:PAM: )?)?
|
||||
# optional suffix (logged from several ssh versions) like " [preauth]"
|
||||
#__suff = (?: port \d+)?(?: \[preauth\])?\s*
|
||||
__suff = (?: (?:port \d+|on \S+|\[preauth\])){0,3}\s*
|
||||
__on_port_opt = (?: (?:port \d+|on \S+)){0,2}
|
||||
# close by authenticating user:
|
||||
__authng_user = (?: (?:invalid|authenticating) user <F-USER>\S+|.*?</F-USER>)?
|
||||
|
||||
# for all possible (also future) forms of "no matching (cipher|mac|MAC|compression method|key exchange method|host key type) found",
|
||||
# see ssherr.c for all possible SSH_ERR_..._ALG_MATCH errors.
|
||||
__alg_match = (?:(?:\w+ (?!found\b)){0,2}\w+)
|
||||
|
||||
# PAM authentication mechanism, can be overridden, e. g. `filter = sshd[__pam_auth='pam_ldap']`:
|
||||
__pam_auth = pam_[a-z]+
|
||||
|
||||
[Definition]
|
||||
|
||||
prefregex = ^<F-MLFID>%(__prefix_line)s</F-MLFID>%(__pref)s<F-CONTENT>.+</F-CONTENT>$
|
||||
|
||||
cmnfailre = ^[aA]uthentication (?:failure|error|failed) for <F-USER>.*</F-USER> from <HOST>( via \S+)?%(__suff)s$
|
||||
^User not known to the underlying authentication module for <F-USER>.*</F-USER> from <HOST>%(__suff)s$
|
||||
<cmnfailre-failed-pub-<publickey>>
|
||||
^Failed <cmnfailed> for (?P<cond_inv>invalid user )?<F-USER>(?P<cond_user>\S+)|(?(cond_inv)(?:(?! from ).)*?|[^:]+)</F-USER> from <HOST>%(__on_port_opt)s(?: ssh\d*)?(?(cond_user): |(?:(?:(?! from ).)*)$)
|
||||
^<F-USER>ROOT</F-USER> LOGIN REFUSED FROM <HOST>
|
||||
^[iI](?:llegal|nvalid) user <F-USER>.*?</F-USER> from <HOST>%(__suff)s$
|
||||
^User <F-USER>\S+|.*?</F-USER> from <HOST> not allowed because not listed in AllowUsers%(__suff)s$
|
||||
^User <F-USER>\S+|.*?</F-USER> from <HOST> not allowed because listed in DenyUsers%(__suff)s$
|
||||
^User <F-USER>\S+|.*?</F-USER> from <HOST> not allowed because not in any group%(__suff)s$
|
||||
^refused connect from \S+ \(<HOST>\)
|
||||
^Received <F-MLFFORGET>disconnect</F-MLFFORGET> from <HOST>%(__on_port_opt)s:\s*3: .*: Auth fail%(__suff)s$
|
||||
^User <F-USER>\S+|.*?</F-USER> from <HOST> not allowed because a group is listed in DenyGroups%(__suff)s$
|
||||
^User <F-USER>\S+|.*?</F-USER> from
|
||||
|
||||
<HOST> not allowed because none of user's groups are listed in AllowGroups%(__suff)s$
|
||||
^<F-NOFAIL>%(__pam_auth)s\(sshd:auth\):\s+authentication failure;</F-NOFAIL>(?:\s+(?:(?:logname|e?uid|tty)=\S*)){0,4}\s+ruser=<F-ALT_USER>\S*</F-ALT_USER>\s+rhost=<HOST>(?:\s+user=<F-USER>\S*</F-USER>)?%(__suff)s$
|
||||
^maximum authentication attempts exceeded for <F-USER>.*</F-USER> from <HOST>%(__on_port_opt)s(?: ssh\d*)?%(__suff)s$
|
||||
^User <F-USER>\S+|.*?</F-USER> not allowed because account is locked%(__suff)s
|
||||
^<F-MLFFORGET>Disconnecting</F-MLFFORGET>(?: from)?(?: (?:invalid|authenticating)) user <F-USER>\S+</F-USER> <HOST>%(__on_port_opt)s:\s*Change of username or service not allowed:\s*.*\[preauth\]\s*$
|
||||
^Disconnecting: Too many authentication failures(?: for <F-USER>\S+|.*?</F-USER>)?%(__suff)s$
|
||||
^<F-NOFAIL>Received <F-MLFFORGET>disconnect</F-MLFFORGET></F-NOFAIL> from <HOST>%(__on_port_opt)s:\s*11:
|
||||
<mdre-<mode>-other>
|
||||
^<F-MLFFORGET><F-MLFGAINED>Accepted \w+</F-MLFGAINED></F-MLFFORGET> for <F-USER>\S+</F-USER> from <HOST>(?:\s|$)
|
||||
|
||||
cmnfailed-any = \S+
|
||||
cmnfailed-ignore = \b(?!publickey)\S+
|
||||
cmnfailed-invalid = <cmnfailed-ignore>
|
||||
cmnfailed-nofail = (?:<F-NOFAIL>publickey</F-NOFAIL>|\S+)
|
||||
cmnfailed = <cmnfailed-<publickey>>
|
||||
|
||||
mdre-normal =
|
||||
# used to differentiate "connection closed" with and without `[preauth]` (fail/nofail cases in ddos mode)
|
||||
mdre-normal-other = ^<F-NOFAIL><F-MLFFORGET>(Connection closed|Disconnected)</F-MLFFORGET></F-NOFAIL> (?:by|from)%(__authng_user)s <HOST>(?:%(__suff)s|\s*)$
|
||||
|
||||
mdre-ddos = ^Did not receive identification string from <HOST>
|
||||
^kex_exchange_identification: (?:[Cc]lient sent invalid protocol identifier|[Cc]onnection closed by remote host)
|
||||
^Bad protocol version identification '.*' from <HOST>
|
||||
^<F-NOFAIL>SSH: Server;Ltype:</F-NOFAIL> (?:Authname|Version|Kex);Remote: <HOST>-\d+;[A-Z]\w+:
|
||||
^Read from socket failed: Connection <F-MLFFORGET>reset</F-MLFFORGET> by peer
|
||||
# same as mdre-normal-other, but as failure (without <F-NOFAIL>) and [preauth] only:
|
||||
mdre-ddos-other = ^<F-MLFFORGET>(Connection (?:closed|reset)|Disconnected)</F-MLFFORGET> (?:by|from)%(__authng_user)s <HOST>%(__on_port_opt)s\s+\[preauth\]\s*$
|
||||
|
||||
mdre-extra = ^Received <F-MLFFORGET>disconnect</F-MLFFORGET> from <HOST>%(__on_port_opt)s:\s*14: No(?: supported)? authentication methods available
|
||||
^Unable to negotiate with <HOST>%(__on_port_opt)s: no matching <__alg_match> found.
|
||||
^Unable to negotiate a <__alg_match>
|
||||
^no matching <__alg_match> found:
|
||||
# part of mdre-ddos-other, but user name is supplied (invalid/authenticating) on [preauth] phase only:
|
||||
mdre-extra-other = ^<F-MLFFORGET>Disconnected</F-MLFFORGET>(?: from)?(?: (?:invalid|authenticating)) user <F-USER>\S+|.*?</F-USER> <HOST>%(__on_port_opt)s \[preauth\]\s*$
|
||||
|
||||
mdre-aggressive = %(mdre-ddos)s
|
||||
%(mdre-extra)s
|
||||
# mdre-extra-other is fully included within mdre-ddos-other:
|
||||
mdre-aggressive-other = %(mdre-ddos-other)s
|
||||
|
||||
# Parameter "publickey": nofail (default), invalid, any, ignore
|
||||
publickey = nofail
|
||||
# consider failed publickey for invalid users only:
|
||||
cmnfailre-failed-pub-invalid = ^Failed publickey for invalid user <F-USER>(?P<cond_user>\S+)|(?:(?! from ).)*?</F-USER> from <HOST>%(__on_port_opt)s(?: ssh\d*)?(?(cond_user): |(?:(?:(?! from ).)*)$)
|
||||
# consider failed publickey for valid users too (don't need RE, see cmnfailed):
|
||||
cmnfailre-failed-pub-any =
|
||||
# same as invalid, but consider failed publickey for valid users too, just as no failure (helper to get IP and user-name only, see cmnfailed):
|
||||
cmnfailre-failed-pub-nofail = <cmnfailre-failed-pub-invalid>
|
||||
# don't consider failed publickey as failures (don't need RE, see cmnfailed):
|
||||
cmnfailre-failed-pub-ignore =
|
||||
|
||||
cfooterre = ^<F-NOFAIL>Connection from</F-NOFAIL> <HOST>
|
||||
|
||||
failregex = %(cmnfailre)s
|
||||
<mdre-<mode>>
|
||||
%(cfooterre)s
|
||||
|
||||
# Parameter "mode": normal (default), ddos, extra or aggressive (combines all)
|
||||
# Usage example (for jail.local):
|
||||
# [sshd]
|
||||
# mode = extra
|
||||
# # or another jail (rewrite filter parameters of jail):
|
||||
# [sshd-aggressive]
|
||||
# filter = sshd[mode=aggressive]
|
||||
#
|
||||
mode = normal
|
||||
|
||||
#filter = sshd[mode=aggressive]
|
||||
|
||||
ignoreregex =
|
||||
|
||||
maxlines = 1
|
||||
|
||||
journalmatch = _SYSTEMD_UNIT=sshd.service + _COMM=sshd
|
||||
|
||||
# DEV Notes:
|
||||
#
|
||||
# "Failed \S+ for .*? from <HOST>..." failregex uses non-greedy catch-all because
|
||||
# it is coming before use of <HOST> which is not hard-anchored at the end as well,
|
||||
# and later catch-all's could contain user-provided input, which need to be greedily
|
||||
# matched away first.
|
||||
#
|
||||
# Author: Cyril Jaquier, Yaroslav Halchenko, Petr Voralek, Daniel Black and Sergey Brester aka sebres
|
||||
# Rewritten using prefregex (and introduced "mode" parameter) by Serg G. Brester.
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
[pureftpd]
|
||||
enabled = true
|
||||
port = ftp
|
||||
filter = pure-ftpd
|
||||
logpath = /var/log/syslog
|
||||
maxretry = 3
|
||||
|
||||
[postfix-sasl]
|
||||
enabled = true
|
||||
mode = auth
|
||||
logpath = /var/log/mail.log
|
||||
maxretry = 2
|
||||
bantime = 432000 # 5 jours en secondes
|
||||
findtime = 86400 # 24 heures en secondes
|
||||
banaction = iptables-allports
|
||||
|
||||
[apache-fakegooglebot]
|
||||
enabled = true
|
||||
logpath = /var/www/clients/client1/www.abonnel.fr/log/access.log
|
||||
maxretry = 3
|
||||
bantime = 86400
|
||||
|
||||
|
||||
[sshd]
|
||||
enabled = true
|
||||
port = ssh
|
||||
logpath = %(sshd_log)s
|
||||
backend = %(sshd_backend)s
|
||||
bantime = 432000 # 5 jours en secondes
|
||||
maxretry = 3
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
# Sécuriser Postfix avec fail2ban
|
||||
|
||||
Cédrix - 2024-07-24
|
||||
|
||||
## Introduction
|
||||
|
||||
Le fichier [/etc/fail2ban/jail.local](_files/sshd-security/etc/fail2ban/jail.local) est un fichier de configuration pour [Fail2Ban](fail2ban.md) qui spécifie les "jails" à surveiller et les actions à entreprendre en cas de tentatives de connexion échouées ou malveillantes. Chaque jail est configurée pour surveiller un service particulier (comme SSH, Postfix, ou Pure-FTPd) en utilisant des fichiers de filtre définis dans des fichiers séparés, comme [/etc/fail2ban/filter.d/postfix-sasl.conf](_files/sshd-security/etc/fail2ban/filter.d/postfix-sasl.conf).
|
||||
|
||||
Pour renforcer la sécurité de nos services, nous allons configuré Fail2Ban pour surveiller et bloquer les tentatives de connexion malveillantes.
|
||||
|
||||
## Configurer les règles de filtrage postfix-sasl (Ban2Fail)
|
||||
|
||||
La configuration du fichier `/etc/fail2ban/filter.d/postfix-sasl.conf` pour Fail2Ban est utilisée pour détecter les échecs d'authentification SASL (Simple Authentication and Security Layer) dans les journaux de Postfix. Voici une explication détaillée de chaque section et ligne de ce fichier :
|
||||
|
||||
|
||||
- **[INCLUDES]** : Cette section permet d'inclure des configurations communes avant de traiter les définitions spécifiques à ce filtre.
|
||||
- **before = common.conf** : Inclut le fichier `common.conf` avant d'appliquer les définitions de ce fichier. `common.conf` contient des paramètres communs utilisés par plusieurs filtres.
|
||||
|
||||
- **[Definition]** : Cette section contient les définitions spécifiques au filtre.
|
||||
- **_daemon = postfix/smtpd** : Définit le démon à surveiller, ici `postfix/smtpd`, qui est le processus de réception de courrier de Postfix.
|
||||
|
||||
|
||||
- **failregex** : Cette directive définit les expressions régulières utilisées pour détecter les tentatives d'authentification échouées dans les journaux de Postfix.
|
||||
|
||||
Les expressions régulières suivantes sont définies :
|
||||
|
||||
1. `warning: .*\[<HOST>\]: SASL LOGIN authentication failed` :
|
||||
- Cette regex correspond aux lignes de journal qui contiennent un avertissement indiquant un échec d'authentification SASL LOGIN.
|
||||
- **<HOST>** est une variable utilisée par Fail2Ban pour capturer l'adresse IP de l'attaquant.
|
||||
|
||||
2. `improper command pipelining after CONNECT from .*\[<HOST>\]:` :
|
||||
- Cette regex correspond aux lignes de journal indiquant une tentative de connexion incorrecte après la commande CONNECT, souvent indicative de comportements suspects ou de tentatives de contournement des protocoles de sécurité.
|
||||
|
||||
|
||||
- **ignoreregex** : Cette directive permet de définir des expressions régulières pour ignorer certaines lignes des journaux, même si elles correspondent à `failregex`. Dans ce cas, `ignoreregex` est vide, ce qui signifie qu'aucune ligne n'est ignorée.
|
||||
|
||||
|
||||
|
||||
|
||||
## Vérifier la jail postfix-sasl (Fail2Ban)
|
||||
|
||||
L'utilisation de la commande `sudo fail2ban-client status postfix-sasl` est destinée à vérifier l'état du service Fail2Ban pour la jail spécifique `postfix-sasl`. Cette commande affiche des informations sur les adresses IP qui ont été bannies et les actions effectuées par Fail2Ban pour protéger le serveur de messagerie Postfix contre les tentatives de connexion SASL (Simple Authentication and Security Layer) échouées.
|
||||
|
||||
Voici comment cette commande fonctionne et ce que chaque partie signifie :
|
||||
|
||||
1. **sudo** : Exécute la commande avec des privilèges administratifs.
|
||||
2. **fail2ban-client** : Interface en ligne de commande pour interagir avec le service Fail2Ban.
|
||||
3. **status** : Paramètre de la commande Fail2Ban pour afficher l'état.
|
||||
4. **postfix-sasl** : Nom de la jail pour laquelle l'état est demandé.
|
||||
|
||||
### Exemple de sortie de la commande
|
||||
|
||||
Lors de l'exécution de la commande, la sortie pourrait ressembler à ceci :
|
||||
|
||||
```
|
||||
Status for the jail: postfix-sasl
|
||||
|- Filter
|
||||
| |- Currently failed: 3
|
||||
| |- Total failed: 124
|
||||
| `- File list: /var/log/mail.log
|
||||
`- Actions
|
||||
|- Currently banned: 2
|
||||
|- Total banned: 5
|
||||
`- Banned IP list: 192.168.1.100 192.168.1.101
|
||||
```
|
||||
|
||||
### Explication des résultats
|
||||
|
||||
- **Currently failed** : Nombre de tentatives de connexion échouées actuellement enregistrées.
|
||||
- **Total failed** : Nombre total de tentatives de connexion échouées depuis la dernière réinitialisation.
|
||||
- **File list** : Liste des fichiers de log surveillés pour détecter les tentatives de connexion échouées.
|
||||
- **Currently banned** : Nombre d'adresses IP actuellement bannies.
|
||||
- **Total banned** : Nombre total d'adresses IP bannies depuis la dernière réinitialisation.
|
||||
- **Banned IP list** : Liste des adresses IP actuellement bannies.
|
||||
|
||||
|
|
@ -0,0 +1,87 @@
|
|||
# Sécuriser Postfix avec fail2ban
|
||||
|
||||
Cédrix - 2024-07-24
|
||||
|
||||
## Introduction
|
||||
|
||||
Le fichier [/etc/fail2ban/jail.local](_files/sshd-security/etc/fail2ban/jail.local) est un fichier de configuration pour Fail2Ban qui spécifie les "jails" à surveiller et les actions à entreprendre en cas de tentatives de connexion échouées ou malveillantes. Chaque jail est configurée pour surveiller un service particulier (comme SSH, Postfix, ou Pure-FTPd) en utilisant des fichiers de filtre définis dans des fichiers séparés, comme [/etc/fail2ban/filter.d/sshd.conf](sshd-security/etc/fail2ban/filter.d/sshd.conf).
|
||||
|
||||
Pour renforcer la sécurité de nos services, nous allons configuré Fail2Ban pour surveiller et bloquer les tentatives de connexion malveillantes.
|
||||
|
||||
## Configurer les règles de filtrage sshd (Ban2Fail)
|
||||
|
||||
La configuration du fichier `/etc/fail2ban/filter.d/sshd.conf` pour Fail2Ban permet de définir les règles de filtrage des journaux SSH pour détecter et bloquer les tentatives de connexion malveillantes. Voici une explication détaillée des différentes sections et lignes de ce fichier :
|
||||
|
||||
### [INCLUDES]
|
||||
|
||||
Cette section inclut des configurations communes à partir du fichier `common.conf`. Cela permet de partager des paramètres communs entre plusieurs fichiers de configuration.
|
||||
|
||||
### [DEFAULT]
|
||||
|
||||
- **_daemon = sshd** : Définit le démon à surveiller, ici `sshd` (le serveur SSH).
|
||||
- **__pref** et **__suff** : Définit les préfixes et suffixes facultatifs qui peuvent apparaître dans les journaux SSH, pour tenir compte des variations entre différentes versions et configurations de SSH.
|
||||
- **__on_port_opt** : Définit des options supplémentaires pour le port, comme "port" ou "on".
|
||||
- **__authng_user** : Modèle pour les utilisateurs en cours d'authentification ou invalides.
|
||||
- **__alg_match** : Modèle pour les erreurs de correspondance d'algorithmes.
|
||||
- **__pam_auth** : Définit le mécanisme d'authentification PAM utilisé.
|
||||
|
||||
### [Definition]
|
||||
|
||||
- **prefregex** : Expression régulière pour identifier les lignes de log pertinentes.
|
||||
|
||||
- **cmnfailre** : Définit plusieurs expressions régulières pour détecter les échecs d'authentification communs, les utilisateurs invalides, les tentatives d'accès refusées, etc.
|
||||
|
||||
- **mdre-normal** : Modèles pour les messages normaux de déconnexion.
|
||||
- **mdre-ddos** : Modèles pour les tentatives de déni de service (DDoS).
|
||||
- **mdre-extra** : Modèles pour des erreurs supplémentaires spécifiques.
|
||||
- **mdre-aggressive** : Combine les modèles `ddos` et `extra`.
|
||||
|
||||
- **publickey** : Paramètre pour gérer les échecs d'authentification par clé publique.
|
||||
|
||||
- **failregex** : Définit les expressions régulières principales utilisées pour détecter les tentatives d'accès échouées.
|
||||
|
||||
- **mode** : Définit le mode de détection, qui peut être `normal`, `ddos`, `extra` ou `aggressive`.
|
||||
|
||||
- **journalmatch** : Filtre pour les journaux systemd, spécifique au service SSH (`sshd.service`).
|
||||
|
||||
|
||||
## Vérifier la jail sshd (Fail2Ban)
|
||||
|
||||
```
|
||||
sudo fail2ban-client status sshd
|
||||
```
|
||||
|
||||
La commande `sudo fail2ban-client status sshd` est utilisée pour vérifier l'état du service Fail2Ban pour la jail spécifique `sshd`. Cette jail est configurée pour protéger le serveur SSH contre les tentatives de connexion non autorisées ou échouées.
|
||||
|
||||
Voici comment cette commande fonctionne et ce que chaque partie signifie :
|
||||
|
||||
1. **sudo** : Exécute la commande avec des privilèges administratifs.
|
||||
2. **fail2ban-client** : Interface en ligne de commande pour interagir avec le service Fail2Ban.
|
||||
3. **status** : Paramètre de la commande Fail2Ban pour afficher l'état.
|
||||
4. **sshd** : Nom de la jail pour laquelle l'état est demandé.
|
||||
|
||||
### Exemple de sortie de la commande
|
||||
|
||||
Lors de l'exécution de la commande, la sortie pourrait ressembler à ceci :
|
||||
|
||||
```
|
||||
Status for the jail: sshd
|
||||
|- Filter
|
||||
| |- Currently failed: 2
|
||||
| |- Total failed: 56
|
||||
| `- File list: /var/log/auth.log
|
||||
`- Actions
|
||||
|- Currently banned: 1
|
||||
|- Total banned: 12
|
||||
`- Banned IP list: 203.0.113.45
|
||||
```
|
||||
|
||||
### Explication des résultats
|
||||
|
||||
- **Currently failed** : Nombre de tentatives de connexion échouées actuellement enregistrées.
|
||||
- **Total failed** : Nombre total de tentatives de connexion échouées depuis la dernière réinitialisation.
|
||||
- **File list** : Liste des fichiers de log surveillés pour détecter les tentatives de connexion échouées, généralement `/var/log/auth.log` pour SSH.
|
||||
- **Currently banned** : Nombre d'adresses IP actuellement bannies.
|
||||
- **Total banned** : Nombre total d'adresses IP bannies depuis la dernière réinitialisation.
|
||||
- **Banned IP list** : Liste des adresses IP actuellement bannies.
|
||||
|
||||
|
|
@ -0,0 +1,160 @@
|
|||
# Sécuriser Postfix avec fail2ban
|
||||
|
||||
Cédrix - 2024-07-24
|
||||
|
||||
## Introduction
|
||||
|
||||
Fail2Ban est un logiciel de sécurité conçu pour protéger les systèmes informatiques contre les attaques par force brute et d'autres comportements malveillants. Il fonctionne en surveillant les fichiers de journalisation des services et en prenant des mesures automatisées pour bloquer les adresses IP suspectes.
|
||||
|
||||
|
||||
### Fonctionnement de Fail2Ban
|
||||
|
||||
1. **Surveillance des journaux :**
|
||||
Fail2Ban surveille les fichiers de log des différents services sur un système, tels que SSH, Apache, Postfix, etc. Lorsqu'une tentative de connexion échouée ou un comportement suspect est détecté, il enregistre l'adresse IP de l'attaquant.
|
||||
|
||||
2. **Détection des attaques :**
|
||||
Grâce à des expressions régulières définies dans ses fichiers de configuration, Fail2Ban identifie les tentatives de connexion échouées, les erreurs d'authentification, et d'autres types de comportements malveillants.
|
||||
|
||||
3. **Actions automatisées :**
|
||||
Lorsque le nombre de tentatives échouées pour une adresse IP dépasse un certain seuil (défini dans la configuration), Fail2Ban peut prendre des mesures automatisées telles que :
|
||||
- Ajouter une règle au pare-feu pour bloquer l'adresse IP.
|
||||
- Envoyer des notifications par email à l'administrateur.
|
||||
- Exécuter des scripts personnalisés pour répondre à l'incident.
|
||||
|
||||
### Composants principaux de Fail2Ban
|
||||
|
||||
1. **Fail2Ban Server :**
|
||||
Le serveur Fail2Ban est le processus principal qui exécute les actions de surveillance et de blocage. Il lit les fichiers de configuration, surveille les journaux et applique les actions définies.
|
||||
|
||||
2. **Fail2Ban Client :**
|
||||
Le client Fail2Ban est une interface en ligne de commande qui permet aux utilisateurs d'interagir avec le serveur Fail2Ban. Il est utilisé pour vérifier l'état des jails, débloquer des adresses IP, redémarrer le serveur Fail2Ban, etc.
|
||||
|
||||
3. **Fichiers de configuration :**
|
||||
Les fichiers de configuration de Fail2Ban se trouvent généralement dans le répertoire `/etc/fail2ban/`. Ils incluent :
|
||||
- **jail.conf** et **jail.local** : Définissent les jails et les paramètres globaux.
|
||||
- **filter.d/** : Contient les filtres spécifiques aux services, qui définissent les expressions régulières pour détecter les comportements suspects.
|
||||
- **action.d/** : Contient les actions spécifiques que Fail2Ban peut prendre lorsqu'une attaque est détectée.
|
||||
|
||||
### Processus de blocage
|
||||
|
||||
1. **Détection :**
|
||||
Fail2Ban utilise les filtres définis pour analyser les journaux des services. Lorsqu'une ligne correspondant à une tentative de connexion échouée ou à une erreur d'authentification est trouvée, elle est enregistrée.
|
||||
|
||||
2. **Comptage des tentatives :**
|
||||
Fail2Ban garde une trace du nombre de tentatives échouées pour chaque adresse IP. Si le nombre de tentatives échouées dépasse le seuil défini (par exemple, 3 tentatives), l'adresse IP est considérée comme suspecte.
|
||||
|
||||
3. **Application des actions :**
|
||||
Une fois qu'une adresse IP est identifiée comme suspecte, Fail2Ban applique les actions définies dans sa configuration. Cela peut inclure l'ajout d'une règle au pare-feu pour bloquer l'adresse IP pendant une certaine période.
|
||||
|
||||
### Avantages de Fail2Ban
|
||||
|
||||
1. **Automatisation :**
|
||||
Fail2Ban permet de bloquer automatiquement les adresses IP suspectes sans intervention manuelle, réduisant ainsi la charge de travail des administrateurs système.
|
||||
|
||||
2. **Personnalisation :**
|
||||
Les fichiers de configuration de Fail2Ban sont hautement personnalisables, permettant aux administrateurs de définir des règles spécifiques pour chaque service et de configurer les actions à prendre en cas d'attaque.
|
||||
|
||||
3. **Extensibilité :**
|
||||
Fail2Ban peut être étendu pour surveiller n'importe quel service qui génère des journaux en texte clair, en ajoutant simplement des filtres et des jails appropriés.
|
||||
|
||||
4. **Protection en temps réel :**
|
||||
Fail2Ban fournit une protection en temps réel contre les attaques par force brute et d'autres comportements malveillants, améliorant ainsi la sécurité globale du système.
|
||||
|
||||
|
||||
## Installer Fail2Ban sous Debian 12
|
||||
|
||||
Pour installer Fail2Ban sous Debian 12, suivez les étapes ci-dessous :
|
||||
|
||||
### Étape 1 : Mettre à jour les paquets
|
||||
|
||||
Avant d'installer Fail2Ban, il est recommandé de mettre à jour la liste des paquets et les paquets installés sur votre système Debian. Ouvrez un terminal et exécutez les commandes suivantes :
|
||||
|
||||
```sh
|
||||
sudo apt update
|
||||
sudo apt upgrade -y
|
||||
```
|
||||
|
||||
### Étape 2 : Installer Fail2Ban
|
||||
|
||||
Installez le paquet Fail2Ban en utilisant `apt` :
|
||||
|
||||
```sh
|
||||
sudo apt install fail2ban -y
|
||||
```
|
||||
|
||||
### Étape 3 : Vérifier l'installation
|
||||
|
||||
Après l'installation, vérifiez que le service Fail2Ban est correctement installé et fonctionne en vérifiant son statut :
|
||||
|
||||
```sh
|
||||
sudo systemctl status fail2ban
|
||||
```
|
||||
|
||||
Vous devriez voir une sortie indiquant que le service Fail2Ban est actif et en cours d'exécution.
|
||||
|
||||
### Étape 4 : Configuration de base
|
||||
|
||||
1. **Créer un fichier de configuration local :**
|
||||
|
||||
Pour personnaliser la configuration de Fail2Ban sans modifier les fichiers de configuration par défaut, créez un fichier `jail.local` à partir du fichier de configuration par défaut `jail.conf` :
|
||||
|
||||
```sh
|
||||
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
|
||||
```
|
||||
|
||||
2. **Éditer le fichier `jail.local` :**
|
||||
|
||||
Ouvrez le fichier `jail.local` avec votre éditeur de texte préféré :
|
||||
|
||||
```sh
|
||||
sudo nano /etc/fail2ban/jail.local
|
||||
```
|
||||
|
||||
Apportez les modifications nécessaires pour configurer les jails que vous souhaitez activer. Par exemple, pour activer la protection SSH, recherchez la section `[sshd]` et définissez `enabled` à `true` :
|
||||
|
||||
```ini
|
||||
[sshd]
|
||||
enabled = true
|
||||
port = ssh
|
||||
logpath = %(sshd_log)s
|
||||
backend = %(sshd_backend)s
|
||||
```
|
||||
|
||||
Vous pouvez configurer d'autres options comme `maxretry`, `bantime`, et `findtime` selon vos besoins.
|
||||
|
||||
### Étape 5 : Redémarrer Fail2Ban
|
||||
|
||||
Après avoir modifié la configuration, redémarrez le service Fail2Ban pour appliquer les changements :
|
||||
|
||||
```sh
|
||||
sudo systemctl restart fail2ban
|
||||
```
|
||||
|
||||
### Étape 6 : Vérifier le statut des jails
|
||||
|
||||
Pour vérifier que vos jails sont correctement configurées et actives, utilisez la commande suivante :
|
||||
|
||||
```sh
|
||||
sudo fail2ban-client status
|
||||
```
|
||||
|
||||
Cette commande affichera un résumé des jails activées et leur statut.
|
||||
|
||||
### Étape 7 : Vérifier les logs de Fail2Ban
|
||||
|
||||
Pour vérifier que Fail2Ban fonctionne correctement et bannit les adresses IP malveillantes, consultez les logs de Fail2Ban :
|
||||
|
||||
```sh
|
||||
sudo tail -f /var/log/fail2ban.log
|
||||
```
|
||||
|
||||
## Autres articles
|
||||
|
||||
- [Sécuriser Postfix avec fail2ban](fail2ban-postfix-sasl.md)
|
||||
|
||||
- [Sécuriser sshd avec fail2ban](fail2ban-sshd.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,60 @@
|
|||
# Rendre accessible Clamav à NextCloud
|
||||
|
||||
Cédrix - 2024-07-22
|
||||
|
||||
## Introduction
|
||||
|
||||
Vous avez raison de vous préoccuper de la sécurité en ouvrant `open_basedir` pour inclure `/usr/bin`. Permettre l'accès à ce répertoire peut exposer votre serveur à des risques potentiels, car cela donne à PHP l'accès à tous les exécutables de ce répertoire.
|
||||
|
||||
Voici quelques suggestions pour atténuer les risques de sécurité tout en permettant à votre programme PHP d'utiliser `clamscan` :
|
||||
|
||||
1. **Utiliser `clamscan` via un wrapper** : Au lieu d'ouvrir `/usr/bin` en entier, vous pourriez créer un script wrapper qui appelle `clamscan` et placer ce script dans un répertoire déjà inclus dans `open_basedir`. Par exemple, créez un script shell `/var/www/clients/client1/web8/web/clamscan_wrapper.sh` :
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
/usr/bin/clamscan "$@"
|
||||
```
|
||||
|
||||
Assurez-vous que ce script est exécutable :
|
||||
|
||||
```bash
|
||||
chmod +x /var/www/clients/client1/web8/web/clamscan_wrapper.sh
|
||||
```
|
||||
|
||||
Vous pouvez ensuite appeler ce script depuis PHP :
|
||||
|
||||
```php
|
||||
<?php
|
||||
$output = shell_exec('/var/www/clients/client1/web8/web/clamscan_wrapper.sh /path/to/file');
|
||||
echo $output;
|
||||
?>
|
||||
```
|
||||
|
||||
2. **Configurer les permissions de fichier** : Assurez-vous que seuls les utilisateurs nécessaires ont accès au script wrapper et aux fichiers qu'il scanne. Limitez les permissions autant que possible.
|
||||
|
||||
3. **Utiliser `suexec` ou `php-fpm`** : Si vous utilisez Apache, vous pouvez envisager de configurer `suexec` pour exécuter des scripts en tant qu'utilisateur spécifique, ce qui peut aider à limiter l'impact potentiel des failles de sécurité. Pour `php-fpm`, configurez des pools de processus avec des utilisateurs spécifiques pour chaque site ou application.
|
||||
|
||||
4. **Auditer et surveiller** : Mettez en place des mécanismes d'audit et de surveillance pour détecter toute activité suspecte. Les logs peuvent être très utiles pour repérer des comportements anormaux.
|
||||
|
||||
5. **Limiter l'accès réseau** : Assurez-vous que le serveur ne permet pas d'accès non autorisé depuis l'extérieur et utilisez un pare-feu pour limiter les connexions entrantes et sortantes.
|
||||
|
||||
Voici un exemple de script wrapper et de configuration PHP pour appeler `clamscan` :
|
||||
|
||||
### Script Wrapper (`/var/www/clients/client1/web8/web/clamscan_wrapper.sh`)
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
/usr/bin/clamscan "$@"
|
||||
```
|
||||
|
||||
### Code PHP
|
||||
|
||||
```php
|
||||
<?php
|
||||
$file_to_scan = '/path/to/file';
|
||||
$clamscan_output = shell_exec('/var/www/clients/client1/web8/web/clamscan_wrapper.sh ' . escapeshellarg($file_to_scan));
|
||||
echo $clamscan_output;
|
||||
?>
|
||||
```
|
||||
|
||||
En suivant ces pratiques, vous pouvez réduire les risques de sécurité associés à l'ouverture de `open_basedir` tout en permettant à votre programme PHP d'utiliser `clamscan`.
|
||||
Loading…
Reference in New Issue