Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 15/04/2021, à 09:16

Matteo13

[Résolu] Configuration fail2ban et problème d'heure sur auth.log

Bonjour,

Je viens vers vous car j'ai plusieurs problème.
Mon problème de base vient du fait que je voulais limiter les tentatives de connexion sur le port 22 sur mon raspberry. J'ai donc installé fail2ban. Avant de passer sur le ssh sur un autre port que le 22 pour limiter les tentatives d'intrusion sur ce port, je voulais m'assurer que fail2ban fonctionnait bien. En vérifiant que celui-ci fonctionnait bien, je me suis rendu compte qu'il ne bloquait rien. J'ai pourtant l'impression que ma configuration est bonne (j'ai bien mis la valeur enabled=true, et donné des valeurs à maxretry et bantime qui devraient me permettre de bloquer des adresses ip dans un fichier jail.local).

En farfouillant dans auth.log, je me suis rendu compte que mes logs dans ce fichier avaient 2h de retard (ex: une connection qui a lieu a 10h02 est décomptée à 8h02). Je me demande si ceci ne peut pas être une cause du problème.
Ce que je ne comprends pas, c'est que l'instruction "date" me renvoie bien la bonne heure. Ma zone est bien configurée sur Paris dans /etc/timezone

Est-ce que quelqu'un saurait m'expliquer déjà pourquoi mes logs dans auth.log ne sont pas à la bonne heure?

Dernière modification par Matteo13 (Le 29/04/2021, à 09:07)

Hors ligne

#2 Le 15/04/2021, à 09:31

bruno

Re : [Résolu] Configuration fail2ban et problème d'heure sur auth.log

Bonjour,

Pour sécuriser un serveur SSH il faut avant tout privilégier les connexions par clé et si possible interdire les connexions par mot de passe (sinon utiliser des mots de passe très forts).
Le changement de port n'apporte aucun gain de sécurité, cela peut même la diminuer si le port choisi est > 1024

Fail2ban s'utilise en dernier recours pour diminuer la probabilité de succès d'une attaque par force brute si la connexion par mot de passe est autorisée. C'est plus un outil pour limiter les connexions inutiles et le remplissage des logs qu'un élément de sécurité.

Pour tes problèmes, il faut montrer ta configuration. Ce que tu as créé, modifié pour fail2ban, si tu as bien relancé le service, etc.
Le décalage de deux heures correspond à celui entre l'heure locale en France et l'heure UTC. Vérifie bien tes paramètres de date et donne le retour de :

timedatctl

Hors ligne

#3 Le 15/04/2021, à 09:31

jpoc

Re : [Résolu] Configuration fail2ban et problème d'heure sur auth.log

Heure locale ou heure GMT : il y a 2 heures de decalage en été

Hors ligne

#4 Le 15/04/2021, à 09:48

Matteo13

Re : [Résolu] Configuration fail2ban et problème d'heure sur auth.log

Merci pour l'aide et la réponse rapide.

bruno a écrit :

Pour sécuriser un serveur SSH il faut avant tout privilégier les connexions par clé et si possible interdire les connexions par mot de passe (sinon utiliser des mots de passe très forts).
Le changement de port n'apporte aucun gain de sécurité, cela peut même la diminuer si le port choisi est > 1024

OK, c'est clair. C'est ce qu'il faut que je fasse.
Bon, le souci, c'est que même si au final fail2ban ne me sera plus utile, j'aimerai bien comprendre ce qui pêche dans ma config...

bruno a écrit :

Pour tes problèmes, il faut montrer ta configuration. Ce que tu as créé, modifié pour fail2ban, si tu as bien relancé le service, etc.

En virant les commentaires, et en ne gardant que le jail sur sshd, voici mon jail.conf

[INCLUDES]

before = paths-debian.conf

[DEFAULT]

ignorecommand =
bantime  = 10m
findtime = 60m
maxretry = 3
maxmatches = %(maxretry)s
backend = auto
usedns = warn
logencoding = auto
enabled = false
mode = normal
filter = %(__name__)s[mode=%(mode)s]


#
# ACTIONS
#

destemail = root@localhost
sender = root@<fq-hostname>
mta = sendmail
protocol = tcp
chain = <known/chain>
port = 0:65535
fail2ban_agent = Fail2Ban/%(fail2ban_version)s
banaction = iptables-multiport
banaction_allports = iptables-allports

action_ = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]

action_mw = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
            %(mta)s-whois[name=%(__name__)s, sender="%(sender)s", dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s"]
action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
             %(mta)s-whois-lines[name=%(__name__)s, sender="%(sender)s", dest="%(destemail)s", logpath="%(logpath)s", chain="%(chain)s"]
action_xarf = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
             xarf-login-attack[service=%(__name__)s, sender="%(sender)s", logpath="%(logpath)s", port="%(port)s"]
action_cf_mwl = cloudflare[cfuser="%(cfemail)s", cftoken="%(cfapikey)s"]
                %(mta)s-whois-lines[name=%(__name__)s, sender="%(sender)s", dest="%(destemail)s", logpath="%(logpath)s", chain="%(chain)s"]
action_blocklist_de  = blocklist_de[email="%(sender)s", service=%(filter)s, apikey="%(blocklist_de_apikey)s", agent="%(fail2ban_agent)s"]
action_badips = badips.py[category="%(__name__)s", banaction="%(banaction)s", agent="%(fail2ban_agent)s"]
action_badips_report = badips[category="%(__name__)s", agent="%(fail2ban_agent)s"]
action_abuseipdb = abuseipdb
action = %(action_)s

#
# JAILS
#

[sshd]

enabled = true
mode    = normal
port    = ssh
filter  = sshd
logpath = /var/log/auth.log #%(sshd_log)s
backend = %(sshd_backend)s
maxretry= 3

Et oui, j'ai bien relancé le service à chaque modif du jail.conf wink

bruno a écrit :

Le décalage de deux heures correspond à celui entre l'heure locale en France et l'heure UTC. Vérifie bien tes paramètres de date et donne le retour de :

timedatctl

C'est ici:

Local time: Thu 2021-04-15 10:35:41 CEST
Universal time: Thu 2021-04-15 08:35:41 UTC
RTC time: n/a
Time zone: Europe/Paris (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

Dernière modification par Matteo13 (Le 15/04/2021, à 09:49)

Hors ligne

#5 Le 15/04/2021, à 09:50

Matteo13

Re : [Résolu] Configuration fail2ban et problème d'heure sur auth.log

jpoc a écrit :

Heure locale ou heure GMT : il y a 2 heures de decalage en été

Merci pour la réponse.
Oui, ça j'ai bien compris le principe du décalage horaire wink
La question que je me pose est est-ce qu'il est normal que le auth.log ne soit pas à l'heure de mon système?

Hors ligne

#6 Le 15/04/2021, à 10:10

bruno

Re : [Résolu] Configuration fail2ban et problème d'heure sur auth.log

Il vaut mieux éviter de modifier le fichier /etc/fail2ban/jail.conf. La configuration doit se faire sous /etc/fail2ban/jail.d Voir la doc fail2ban
D'ailleurs il a peu près sûr que le « jail » sshd était déjà activé via le fichier /etc/fail2ban/jail.d/defaults-debian.conf

Je t'invite donc à remettre la configuration par défaut, à vérifier que le service et les différentes « prisons » sont bien lancés :

systemctl status fail2ban
sudo fail2ban-client status

et à examiner les logs le cas échéant : /var/log/fail2ban.log

Pour l'heure je ne vois pas d'où cela vient mais il est curieux que tu n'ait pas de RTC. Le Raspberry n'a pas d'horloge matérielle mais c'est normalement compensé par fake-hwclock)
Si tu as modifié les réglages d'heure (fuseau horaire, heure locale), il faut au minimum redémarrer le service rsyslog.

Dernière modification par bruno (Le 15/04/2021, à 10:14)

Hors ligne

#7 Le 15/04/2021, à 10:56

Matteo13

Re : [Résolu] Configuration fail2ban et problème d'heure sur auth.log

bruno a écrit :

Il vaut mieux éviter de modifier le fichier /etc/fail2ban/jail.conf. La configuration doit se faire sous /etc/fail2ban/jail.d Voir la doc fail2ban
D'ailleurs il a peu près sûr que le « jail » sshd était déjà activé via le fichier /etc/fail2ban/jail.d/defaults-debian.conf

Je t'invite donc à remettre la configuration par défaut, à vérifier que le service et les différentes « prisons » sont bien lancés :

OK, j'ai récupéré le jail.conf sur github et l'ai remis.
J'ai mis ma config du ssh dans un custom.conf dans jail.d. J'ai aussi changé le temps d'analyse findtime=300m. Peux-têtre que si je mets un temps de plus 2h, ça prendra en compte mon décalage de 2h dans auth.log...??? A voir...

bruno a écrit :
systemctl status fail2ban

Ca c'est bon.

fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2021-04-15 11:40:11 CEST; 10s ago
Docs: man:fail2ban(1)
Process: 17151 ExecStartPre=/bin/mkdir -p /run/fail2ban (code=exited, status=0/SUCCESS)
Main PID: 17152 (f2b/server)
Tasks: 5 (limit: 1826)
CGroup: /system.slice/fail2ban.service
             └─17152 /usr/bin/python3 /usr/bin/fail2ban-server -xf start

Apr 15 11:40:11 ubuntu systemd[1]: Starting Fail2Ban Service...
Apr 15 11:40:11 ubuntu systemd[1]: Started Fail2Ban Service.
Apr 15 11:40:13 ubuntu fail2ban-server[17152]: Server ready
bruno a écrit :
sudo fail2ban-client status

Là aussi, le "jail" ssh est bien lancé.

Status
|- Number of jail:      1
`- Jail list:   sshd

Pour info, il trouve maintenant des "failed", alors qu'il n'en trouvait 0 avant:

ubuntu@ubuntu:/etc/fail2ban/jail.d$ sudo fail2ban-client status sshd
sudo: unable to resolve host ubuntu: Temporary failure in name resolution
Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     191
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:
bruno a écrit :

et à examiner les logs le cas échéant : /var/log/fail2ban.log

Je trouve un WARNING, il faut que je fouille, car je ne comprends pas trop le problème là. Je pense que ça vient de la config d'iptable (cf l'erreur sur le sudo au-dessus que j'ai depuis que j'ai changé des trucs dans iptables). Sinon, j'ai l'impression qu'il s'est bien lancé (je n'ai pas mis toute la liste d'adresses IP qu'il a trouvé):

2021-04-15 11:40:12,624 fail2ban.server         [17152]: INFO    --------------------------------------------------
2021-04-15 11:40:12,627 fail2ban.server         [17152]: INFO    Starting Fail2ban v0.11.1
2021-04-15 11:40:12,631 fail2ban.observer       [17152]: INFO    Observer start...
2021-04-15 11:40:12,646 fail2ban.database       [17152]: INFO    Connected to fail2ban persistent database '/var/lib/fail2ban/fail2ban.sqlite3'
2021-04-15 11:40:12,656 fail2ban.jail           [17152]: INFO    Creating new jail 'sshd'
2021-04-15 11:40:12,734 fail2ban.jail           [17152]: INFO    Jail 'sshd' uses pyinotify {}
2021-04-15 11:40:12,768 fail2ban.jail           [17152]: INFO    Initiated 'pyinotify' backend
2021-04-15 11:40:12,791 fail2ban.filter         [17152]: INFO      maxLines: 1
2021-04-15 11:40:13,098 fail2ban.filter         [17152]: INFO      maxRetry: 3
2021-04-15 11:40:13,100 fail2ban.filter         [17152]: INFO      findtime: 18000
2021-04-15 11:40:13,101 fail2ban.actions        [17152]: INFO      banTime: 600
2021-04-15 11:40:13,102 fail2ban.filter         [17152]: INFO      encoding: UTF-8
2021-04-15 11:40:13,106 fail2ban.filter         [17152]: INFO    Added logfile: '/var/log/auth.log' (pos = 5855552, hash = bf288dcb7825bbc8cf7e1469f1afa6c40f15a001)
2021-04-15 11:40:13,151 fail2ban.jail           [17152]: INFO    Jail 'sshd' started
2021-04-15 11:42:50,473 fail2ban.ipdns          [17152]: WARNING Unable to find a corresponding IP address for ubuntu: [Errno -3] Temporary failure in name resolution
2021-04-15 11:42:50,475 fail2ban.filter         [17152]: INFO    [sshd] Found 47.31.12.160 - 2021-04-15 07:16:56
2021-04-15 11:42:50,481 fail2ban.filter         [17152]: INFO    [sshd] Found 47.31.12.160 - 2021-04-15 07:16:58
2021-04-15 11:42:50,488 fail2ban.filter         [17152]: INFO    [sshd] Found 47.31.12.160 - 2021-04-15 07:17:06
2021-04-15 11:42:50,492 fail2ban.filter         [17152]: INFO    [sshd] Found 47.31.12.160 - 2021-04-15 07:17:08
2021-04-15 11:42:50,496 fail2ban.filter         [17152]: INFO    [sshd] Found 47.31.38.108 - 2021-04-15 07:17:16

Pour l'heure je ne vois pas d'où cela vient mais il est curieux que tu n'ait pas de RTC. Le Raspberry n'a pas d'horloge matérielle mais c'est normalement compensé par fake-hwclock)
Si tu as modifié les réglages d'heure (fuseau horaire, heure locale), il faut au minimum redémarrer le service rsyslog.

Dans le doute, je l'ai relancé, mais je n'ai toujours pas de RTC... Je vais regarder de ce côté là aussi.

Hors ligne

#8 Le 15/04/2021, à 11:49

bruno

Re : [Résolu] Configuration fail2ban et problème d'heure sur auth.log

Cela à l'air de fonctionner…
Est-ce que tu vois 47.31.12.160 dans iptables ?

sudo iptables -L -n

Pour l’avertissement (warning), c'est non bloquant. C'est dû à une machine dont le nom d'hôte est ubuntu et qui ne peut être résolu en IP.
As-tu bien pensé à renseigner la directive ignoreip ?

Dans le doute, je l'ai relancé, mais je n'ai toujours pas de RTC...

Pour l'horloge pseudo matérielle :

sudo apt install fake-hwclock

Hors ligne

#9 Le 16/04/2021, à 17:04

Matteo13

Re : [Résolu] Configuration fail2ban et problème d'heure sur auth.log

Désolé pour le temps de réponse, j'ai été un peu pris au boulot...

bruno a écrit :

Cela à l'air de fonctionner…
Est-ce que tu vois 47.31.12.160 dans iptables ?

sudo iptables -L -n

Non cela n'apparait pas. Par contre, en vérifiant, j'ai bien des IP qui sont bannis, donc ça tourne bien. Merci beaucoup.
Par contre, je ne sais pas si cela vient du fichier de configuration ou du fait que j'ai mis 4h dans le findtime. Pour revenir à la question initiale, est-ce que c'est normal que dans le auth.log les logs ne se fassent pas à l'heure du système, ou cela vient du fait que le RTC n'apparait pas dans mon timedatectl?

bruno a écrit :

Pour l’avertissement (warning), c'est non bloquant. C'est dû à une machine dont le nom d'hôte est ubuntu et qui ne peut être résolu en IP.
As-tu bien pensé à renseigner la directive ignoreip ?

Je l'ai rajouté dans mon jail.d/custom.conf, avec l'adresse ip de l'ordinateur depuis lequel je me connecte en ssh, et aussi depuis 127.0.0.1. C'est bien cela qu'il fallait faire?

brunot a écrit :

Dans le doute, je l'ai relancé, mais je n'ai toujours pas de RTC...

Pour l'horloge pseudo matérielle :

sudo apt install fake-hwclock

C'est installé, lancé (service fake-hwclock status me renvoie bien que le service est actif), et j'ai relancé rsyslog, mais toujours pas de RTC... Il y a autre chose que j'ai oublié de relancer ?

Dernière modification par Matteo13 (Le 16/04/2021, à 17:06)

Hors ligne

#10 Le 16/04/2021, à 17:36

bruno

Re : [Résolu] Configuration fail2ban et problème d'heure sur auth.log

Au temps pour moi sur une Raspberry tu n'auras jamais de RTC. Je viens de tester.

Par contre tu ne devais pas avoir ce décalage de deux heures.
Je te conseille de recommencer les réglages :

sudo dpkg-reconfigure tzdata

et tu réponds aux questions : Europe, Paris
puis tu redémarres ton Raspberry.
Pour vérifier que les logs sont à la bonne heure :

tail -f /var/log/syslog

(Ctrl+C pour sortir)

Hors ligne

#11 Le 29/04/2021, à 09:06

Matteo13

Re : [Résolu] Configuration fail2ban et problème d'heure sur auth.log

Bonjour Bruno,

En effet, cela fonctionne très bien maintenant.

Merci beaucoup pour l'aide.

Hors ligne