Compare commits

...

7 Commits

14 changed files with 878 additions and 7 deletions

View File

@ -1,6 +1,6 @@
MIT License
Copyright (c) 2024 cedricAbonnel / Cédrix
Copyright (c) 2024 Cédrix
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

View File

@ -31,7 +31,7 @@ Le dépôt est organisé en différentes catégories pour faciliter la navigatio
Les contributions sont les bienvenues ! Si vous avez des suggestions, des corrections ou de nouvelles notes à ajouter, veuillez suivre les étapes suivantes :
1. **Fork le dépôt**
2. **Cloner votre fork** : `git clone https://github.com/votre-utilisateur/votre-repo.git`
2. **Cloner votre fork** : `git clone https://xxxx/votre-utilisateur/votre-repo.git`
3. **Créer une branche** : `git checkout -b ma-nouvelle-branche`
4. **Faire des modifications**
5. **Commits** : `git add .` puis `git commit -m "Ajouter une nouvelle note sur [sujet]"`

View File

@ -8,7 +8,7 @@ Merci de votre intérêt pour contribuer à ce projet ! Vos contributions sont e
2. **Cloner votre fork** : Clonez le dépôt forké sur votre machine locale.
```bash
git clone https://github.com/votre-utilisateur/votre-repo.git
git clone https://xxxx/votre-utilisateur/votre-repo.git
```
3. **Créer une branche** : Créez une nouvelle branche pour votre fonctionnalité ou correction.
@ -29,7 +29,7 @@ Merci de votre intérêt pour contribuer à ce projet ! Vos contributions sont e
git push origin ma-nouvelle-branche
```
7. **Créer une Pull Request** : Allez sur la page de votre dépôt forké sur GitHub et cliquez sur "New Pull Request". Décrivez vos modifications dans la description de la Pull Request.
7. **Créer une Pull Request** : Allez sur la page de votre dépôt forké et cliquez sur "New Pull Request". Décrivez vos modifications dans la description de la Pull Request.
## Lignes Directrices pour les Contributions

View File

@ -1,6 +1,6 @@
# Créer une autorité de certification (CA) privée
Cédric Abonnel - 2024-07-21
Cédrix - 2024-07-21
## Introduction
@ -116,7 +116,7 @@ Email Address []: john.doe@example.com
En suivant ces indications, vous aurez correctement configuré les informations de votre CA privée pour un usage personnel.
Le certificat créé (`ca.crt`) sera valide pendant 10 ans (3650 jours).
Le certificat créé (`ca.crt`) sera valide pendant 10 ans (3650 jours).
En suivant ces étapes, vous aurez configuré une structure de base pour votre CA privée sur Debian 12, prête à émettre et gérer des certificats au sein de votre infrastructure.
@ -424,4 +424,20 @@ En suivant ces étapes, vous pourrez révoquer des certificats compromis ou obso
## Références
https://ca-ra.org/fr/comment-installer-et-configurer-une-autorit%C3%A9-de-certification-ca-sur-ubuntu-20-04/
1. **Cyklodev** :
- Ce guide fournit des instructions détaillées sur la création d'une clé privée, la génération d'une demande de signature de certificat (CSR), la vérification de la demande, et la signature du certificat avec OpenSSL.
- [Créer une autorité de certification avec OpenSSL](https://sysadmin.cyklodev.com)
2. **CA-RA** :
- Ce site explique comment installer et configurer une autorité de certification sur Ubuntu 20.04, en utilisant Easy-RSA pour générer les fichiers de certificats publics et privés nécessaires, ainsi que les étapes pour distribuer ces certificats.
- [Comment installer et configurer une autorité de certification sur Ubuntu 20.04](https://ca-ra.org/fr/comment-installer-et-configurer-une-autorit%C3%A9-de-certification-ca-sur-ubuntu-20-04/)
3. **Aymeric Cucherousset** :
- Ce guide aborde la création d'une autorité de certification sous Debian, en détaillant la création du répertoire de la CA, la génération des clés et certificats, ainsi que l'installation des certificats sur diverses plateformes.
- [Créer une autorité de certification](https://aymeric-cucherousset.fr)
4. **Elao** :
- Ce guide explique comment créer une clé et un certificat pour un serveur, ainsi que les étapes pour générer une requête de signature de certificat et signer cette requête avec l'autorité de certification.
- [Créer une autorité de certification et des certificats SSL auto-signés](https://www.elao.com)

View File

@ -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 =

View File

@ -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.

View File

@ -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

View File

@ -0,0 +1,55 @@
#!/usr/bin/env php
<?php
echo "-- Execution de ".__FILE__."\n";
// Créer des fichiers temporaires pour stocker les logs et les IPs
$tempLog = trim(shell_exec('mktemp /tmp/fail2ban_temp.XXXXXX.log'));
$banList = trim(shell_exec('mktemp /tmp/ban_ips.XXXXXX.txt'));
$logFile = "/var/log/mail.log";
$filterFile = "/etc/fail2ban/filter.d/postfix-sasl.conf";
// Utiliser fail2ban-regex pour analyser le fichier de log et extraire les adresses IP correspondantes
exec("sudo fail2ban-regex $logFile $filterFile --print-all-matched > $tempLog");
// Lire le fichier temporaire et extraire les adresses IP
$logContent = file_get_contents($tempLog);
preg_match_all('/\[\K[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+(?=\])/', $logContent, $matches);
// Supprimer les doublons
$ips = array_unique($matches[0]);
// Obtenir la liste des IP déjà bannies
exec("sudo fail2ban-client status postfix-sasl", $output);
$bannedIps = [];
$bannedIpsFound = false;
foreach ($output as $line) {
if (strpos($line, 'Banned IP list:') !== false) {
$bannedIpsFound = true;
$bannedIps = array_merge($bannedIps, preg_split('/\s+/', trim($line)));
} elseif ($bannedIpsFound && trim($line) !== '') {
$bannedIps = array_merge($bannedIps, preg_split('/\s+/', trim($line)));
}
}
// Écrire les adresses IP dans un fichier temporaire
file_put_contents($banList, implode("\n", $ips));
// Lire le fichier contenant les adresses IP et les bannir avec fail2ban-client
foreach ($ips as $ip) {
if (!in_array($ip, $bannedIps)) {
echo "Banning IP: $ip\n";
exec("sudo fail2ban-client set postfix-sasl banip $ip");
}
}
// Nettoyer les fichiers temporaires
unlink($tempLog);
unlink($banList);
echo "All matching IPs have been processed.\n";
echo "-- Fin d'exection de ".__FILE__."\n";
?>

View File

@ -0,0 +1,77 @@
#!/usr/bin/env php
<?php
echo "-- Debut de ".__FILE__."\n";
// Chemin vers le fichier de log
$logFile = '/var/log/mail.log';
// Chemin vers le fichier pour stocker les IDs traités
$processedIdsFile = '/var/log/processed_ids_deferred.txt';
// Fonction pour lire les IDs traités à partir du fichier
function readProcessedIds($file) {
if (!file_exists($file)) {
return [];
}
$content = file_get_contents($file);
return $content ? explode(PHP_EOL, trim($content)) : [];
}
// Fonction pour écrire les IDs traités dans le fichier
function writeProcessedIds($file, $ids) {
file_put_contents($file, implode(PHP_EOL, $ids) . PHP_EOL);
}
// Lire les IDs déjà traités
$processedIds = readProcessedIds($processedIdsFile);
// Expression régulière pour trouver les messages d'erreur spécifiques avec status=deferred et extraire l'ID du message
$pattern = '/postfix\/smtp\[\d+\]: (\w+): .* status=deferred /';
// Lire le fichier de log
$logContent = file_get_contents($logFile);
if ($logContent === false) {
die("Erreur lors de la lecture du fichier de log.\n");
}
// Rechercher les correspondances
preg_match_all($pattern, $logContent, $matches);
// Extraire les IDs de message
$messageIds = array_unique($matches[1]);
if (empty($messageIds)) {
echo "Aucun message à supprimer de la file d'attente.\n";
echo "-- Fin de ".__FILE__."\n";
exit;
}
// Filtrer les IDs pour ne conserver que ceux qui n'ont pas encore été traités
$newMessageIds = array_diff($messageIds, $processedIds);
if (empty($newMessageIds)) {
echo "Tous les messages ont déjà été traités.\n";
echo "-- Fin de ".__FILE__."\n";
exit;
}
// Supprimer les messages de la file d'attente
foreach ($newMessageIds as $messageId) {
$command = "postsuper -d $messageId";
$output = [];
$return_var = 0;
exec($command, $output, $return_var);
if ($return_var === 0) {
echo "Message $messageId supprimé de la file d'attente.\n";
$processedIds[] = $messageId;
} else {
echo "Erreur lors de la suppression du message $messageId de la file d'attente.\n";
}
}
// Mettre à jour le fichier des IDs traités
writeProcessedIds($processedIdsFile, $processedIds);
echo "-- Fin de ".__FILE__."\n";

View File

@ -0,0 +1,188 @@
# Sécuriser Postfix avec fail2ban
Cédrix - 2024-07-24
## Introduction
Le fichier [/etc/fail2ban/jail.local](_files/fail2ban/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/fail2ban/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.
## Tester les règle Fail2ban
`fail2ban-regex` offre un moyen puissant de valider, déboguer et optimiser les filtres Fail2Ban, assurant ainsi que seules les activités malveillantes sont détectées et bloquées.
L'utilisation de `fail2ban-regex` implique principalement deux éléments : le fichier de journal à analyser et le fichier de filtre contenant les expressions régulières. Voici comment vous pouvez l'utiliser :
```sh
fail2ban-regex [fichier_journal] [fichier_filtre]
```
### Exemple Pratique
Supposons que vous souhaitiez tester un filtre Fail2Ban pour les tentatives d'authentification échouées de Postfix SASL. Vous avez un fichier de journal `/var/log/mail.log` et un fichier de filtre `/etc/fail2ban/filter.d/postfix-sasl.conf`.
```sh
sudo fail2ban-regex /var/log/mail.log /etc/fail2ban/filter.d/postfix-sasl.conf
```
Cette commande analysera le fichier de journal en utilisant les expressions régulières définies dans le fichier de filtre et affichera les résultats.
La sortie de `fail2ban-regex` est divisée en plusieurs sections :
1. **Summary** : Un résumé des lignes analysées, du nombre de correspondances trouvées et des lignes ignorées.
2. **Success, Ignored, Missed** : Montre quelles lignes de journal ont été capturées avec succès par les expressions régulières, lesquelles ont été ignorées, et lesquelles ont été manquées.
3. **Matches** : Affiche les correspondances spécifiques trouvées dans les journaux.
4. **Lines** : Montre les lignes de journal exactes qui correspondent ou non aux expressions régulières.
## Automatisation de l'ajout d'adresses IP malveillantes
Comment automatiser l'ajout des adresses IP suspectes détectées dans les journaux de Postfix SASL à Fail2Ban, en utilisant un script PHP ? L'objectif est de renforcer la sécurité de votre serveur de messagerie en bloquant automatiquement les adresses IP qui tentent des connexions malveillantes et qui seraient passées à travers les mailles du filet.
Le script [ban_ip_sasl.php](_files/fail2ban/home/cedrix/ban-ip-sasl.php) est écrit en PHP et utilise Fail2Ban pour analyser les journaux de Postfix SASL, extraire les adresses IP malveillantes et les ajouter à la liste de bannissement.
### Revue de Code : Script PHP pour Automatiser le Bannissement des Adresses IP avec Fail2Ban
Ce script PHP vise à automatiser l'ajout d'adresses IP suspectes détectées dans les journaux de Postfix SASL à la liste de bannissement de Fail2Ban. Voici une revue de code détaillée, mettant en évidence les points forts, les aspects à améliorer et les suggestions pour une meilleure pratique.
#### Points Forts
1. **Automatisation Efficace** : Le script permet d'automatiser le processus de surveillance des journaux et de bannissement des IPs, réduisant ainsi la charge administrative.
2. **Utilisation des Outils Existants** : Le script utilise `fail2ban-regex` et `fail2ban-client`, tirant parti des outils Fail2Ban pour extraire et gérer les adresses IP.
3. **Gestion des Fichiers Temporaires** : La création et la suppression de fichiers temporaires permettent de traiter les données sans laisser de traces inutiles sur le système.
4. **Vérification des IPs Déjà Bannies** : Avant de bannir une adresse IP, le script vérifie si elle est déjà bannie, évitant ainsi des opérations redondantes.
#### Aspects à Améliorer
1. **Utilisation de `exec` et `shell_exec`** : L'utilisation de ces fonctions peut poser des risques de sécurité si les entrées ne sont pas correctement échappées. Bien que ce script soit destiné à un usage interne, il est crucial de minimiser les risques d'injection de commandes.
2. **Gestion des Erreurs** : Le script ne gère pas les erreurs potentielles de manière exhaustive. Par exemple, si `fail2ban-regex` ou `fail2ban-client` échoue, le script ne le détecte pas et continue son exécution.
3. **Permissions** : L'exécution de commandes avec `sudo` nécessite que le script soit exécuté avec les privilèges appropriés. Une meilleure approche pourrait être d'exécuter le script en tant qu'utilisateur root directement, ou de configurer `sudo` pour permettre des commandes spécifiques sans mot de passe.
4. **Validation des Entrées et des Sorties** : Avant d'exécuter les commandes, valider les chemins des fichiers et les entrées pour s'assurer qu'ils sont sûrs et existent.
5. **Gestion des Erreurs** : Implémentez une gestion des erreurs robustes en vérifiant les codes de retour des commandes et en ajoutant des messages d'erreur appropriés.
6. **Logging** : Ajouter des logs pour suivre les actions du script, ce qui facilite le débogage et la surveillance des opérations.
7. **Sécurisation des Commandes** : Utiliser des fonctions PHP pour échapper correctement les arguments de commande et minimiser les risques d'injection.
8. **Documentation** : Ajouter des commentaires détaillés et une documentation pour expliquer le fonctionnement du script et les prérequis nécessaires.
#### Exemple d'Amélioration pour la Gestion des Erreurs
Au lieu de :
```php
exec("sudo fail2ban-regex $logFile $filterFile --print-all-matched > $tempLog");
```
Vous pouvez utiliser :
```php
$returnVar = 0;
$output = [];
exec("sudo fail2ban-regex " . escapeshellarg($logFile) . " " . escapeshellarg($filterFile) . " --print-all-matched > " . escapeshellarg($tempLog), $output, $returnVar);
if ($returnVar !== 0) {
echo "Erreur lors de l'exécution de fail2ban-regex.\n";
exit(1);
}
```
Après 12 heures de fonctionnement, il y a plus de 388 adresses repertoriées.
```log
Status for the jail: postfix-sasl
|- Filter
| |- Currently failed: 31
| |- Total failed: 31
| `- File list: /var/log/mail.log
`- Actions
|- Currently banned: 388
|- Total banned: 388
`- Banned IP list: x.x.x.x x.x.x.x x.x.x.x x.x.x.x x.x.x.x
...
```
### Retour d'expérience
Après seulement 12 heures de fonctionnement, le script a permis de répertorier plus de 388 adresses IP suspectes.
Ce résultat impressionnant laisse entrevoir la possibilité de développer un service en ligne qui centraliserait ces adresses IP suspectes à l'instar de [SpamHaus](https://spamhaus.org). Voici comment ce service pourrait fonctionner et les avantages qu'il apporterait :
1. **Centralisation des Données**
- Le service recueillerait les adresses IP suspectes de différents serveurs et sources. Chaque serveur exécutant le script pourrait envoyer ses données à une base de données centralisée.
2. **Base de Données Partagée**
- Les adresses IP recueillies seraient stockées dans une base de données accessible en ligne. Cette base de données serait régulièrement mise à jour et maintenue pour assurer la pertinence des informations.
3. **API d'Interrogation**
- Un API (Application Programming Interface) permettrait une interaction avec les données. Cela faciliterait l'intégration avec d'autres systèmes de sécurité et permettrait une réponse rapide aux menaces potentielles.
4. **Rapports et Analyses**
- Le service pourrait générer des rapports détaillés sur les tendances des attaques, les adresses IP les plus fréquentes, et les types d'attaques les plus courants. Ces informations seraient précieuses pour ajuster les stratégies de sécurité.
6. **Accès Sécurisé**
- Pour garantir la sécurité et l'intégrité des données, l'accès à ce service en ligne serait restreint aux utilisateurs autorisés. Des mesures de sécurité, telles que l'authentification multi-facteurs, seraient mises en place.
## 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.

View File

@ -0,0 +1,87 @@
# Sécuriser Postfix avec fail2ban
Cédrix - 2024-07-24
## Introduction
Le fichier [/etc/fail2ban/jail.local](_files/fail2ban/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](_files/fail2ban/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.

160
notes/serveur/fail2ban.md Normal file
View File

@ -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)

View File

@ -0,0 +1,60 @@
# Automatisation de la Gestion des Messages Différés de Postfix avec un Script PHP
L'objectif du script PHP [delete_deferred.php](_files/postfix/home/cedrix/delete_deferred.php) est de gérer automatiquement les messages de courrier électronique en attente dans la file d'attente de Postfix, spécifiquement ceux avec un statut `deferred` dans `/var/log/mail.log`. Le script identifie ces messages, les supprime de la file d'attente et garde une trace des messages dans déjà traités `/var/log/processed_ids_deferred.txt` pour éviter les traitements redondants.
## Fonctionnalités Principales
1. **Initialisation et Configuration**
- Le script commence par définir les chemins vers le fichier de journal de Postfix et le fichier utilisé pour stocker les IDs des messages déjà traités.
2. **Lecture des IDs Traités**
- Une fonction lit les IDs des messages déjà traités à partir d'un fichier de suivi, assurant que les messages ne sont pas traités plusieurs fois.
3. **Recherche des Messages Différés**
- Utilise une expression régulière pour analyser le fichier de journal de Postfix et identifier les messages avec le statut `deferred`.
4. **Filtrage des Messages Non Traités**
- Compare les IDs des messages trouvés dans le journal avec ceux déjà traités pour ne conserver que les nouveaux messages à traiter.
5. **Suppression des Messages de la File d'Attente**
- Pour chaque nouveau message identifié, le script exécute la commande `postsuper -d` pour supprimer le message de la file d'attente.
- Si la suppression est réussie, l'ID du message est ajouté à la liste des IDs traités.
6. **Mise à Jour du Fichier des IDs Traités**
- Après avoir traité les nouveaux messages, le script met à jour le fichier de suivi avec les nouveaux IDs, garantissant qu'ils ne seront pas traités à nouveau lors de la prochaine exécution.
## Déroulement du Script
1. **Affichage de Début d'Exécution**
- Le script commence par afficher un message indiquant son démarrage.
2. **Définition des Chemins des Fichiers**
- Les variables `$logFile` et `$processedIdsFile` sont définies pour stocker les chemins vers les fichiers nécessaires.
3. **Fonctions de Lecture et Écriture**
- Deux fonctions, `readProcessedIds` et `writeProcessedIds`, sont définies pour lire et écrire les IDs des messages traités.
Le script utilise un fichier spécifique pour stocker les IDs des messages déjà traités. Ce fichier est situé à `/var/log/processed_ids_deferred.txt`.
4. **Lecture et Analyse du Journal**
- Le fichier de journal de Postfix est lu, et les messages correspondant au statut `deferred` sont identifiés à l'aide d'une expression régulière.
5. **Traitement des Messages**
- Les IDs des messages différés sont extraits et filtrés pour ne conserver que ceux qui n'ont pas encore été traités.
- Pour chaque nouveau message, la commande `postsuper -d` est exécutée pour supprimer le message de la file d'attente.
- Les IDs des messages réussis sont ajoutés à la liste des IDs traités.
6. **Mise à Jour des IDs Traités**
- Le fichier des IDs traités est mis à jour avec les nouveaux IDs après le traitement.
7. **Affichage de Fin d'Exécution**
- Le script affiche un message indiquant la fin de l'exécution.
## Avantages du Script
- **Automatisation** : Réduit la nécessité d'intervention manuelle pour gérer les messages différés dans Postfix.
- **Efficacité** : Assure que les messages sont traités de manière efficace en évitant les traitements redondants.
- **Traçabilité** : Garde une trace des messages déjà traités, ce qui facilite le suivi et la gestion des opérations.
## À consulter
- `postsuper`

View File

@ -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`.