Pour le test, j’ai utilisé des scanneurs de port en ligne, mon adresse ip personnelle étant ignorée: résultat positif.
Exemple de mail reçu :
The IP 194.78.194.24 has just been banned by Fail2Ban after
1 attempts against portsentry.
Here is more information about 194.78.194.24 :
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '194.78.194.0 - 194.78.194.255'
% Abuse contact for '194.78.194.0 - 194.78.194.255' is 'abuse@proximus.com'
inetnum: 194.78.194.0 - 194.78.194.255
netname: BE-SKYNET-20011108
descr: ADSL-PREMIUM
descr: Belgacom ISP SA/NV
country: BE
admin-c: SN2068-RIPE
tech-c: SN2068-RIPE
remarks: rev-srv: ns1.skynet.be
remarks: rev-srv: ns2.skynet.be
remarks: rev-srv: ns3.skynet.be
remarks: rev-srv: ns4.skynet.be
status: ASSIGNED PA
mnt-by: SKYNETBE-MNT
mnt-by: SKYNETBE-ROBOT-MNT
created: 2005-03-18T14:41:54Z
last-modified: 2009-09-02T17:55:48Z
source: RIPE
remarks: rev-srv attribute deprecated by RIPE NCC on 02/09/2009
role: Proximus NOC administrators
address: Proximus SA de droit public
address: TEC/NEO/IPR/TDN/DTO/DSL Internet Networks
address: Boulevard du Roi Albert II, 27
address: B-1030 Bruxelles
address: Belgium
phone: +32 2 202-4111
fax-no: +32 2 203-6593
abuse-mailbox: abuse@proximus.com
admin-c: BIEC1-RIPE
tech-c: BIEC1-RIPE
nic-hdl: SN2068-RIPE
remarks: ******************************************
remarks: Abuse notifications to: abuse@proximus.com
remarks: Abuse mails sent to other addresses will be ignored !
remarks: ******************************************
remarks: Network problems to: noc@skynet.be
remarks: Peering requests to: peering@skynet.be
mnt-by: SKYNETBE-MNT
created: 1970-01-01T00:00:00Z
last-modified: 2020-03-04T06:19:15Z
source: RIPE # Filtered
% Information related to '194.78.0.0/16AS5432'
route: 194.78.0.0/16
descr: SKYNETBE-CUSTOMERS
origin: AS5432
mnt-by: SKYNETBE-MNT
created: 1970-01-01T00:00:00Z
last-modified: 2001-09-22T09:32:38Z
source: RIPE # Filtered
% This query was served by the RIPE Database Query Service version 1.97.1 (WAGYU)
Lines containing failures of 194.78.194.24
Regards,
Fail2BanRemarque à moi-même: pour savoir quel port à été snifé dans le mail de fail2ban, il faudrait commenter KILL_RUN_CMD="/usr/bin/fail2ban-client set portsentry banip $TARGET$" et modifier le filtre de fail2ban pour qu’il regarde le fichier /var/lib/portsentry/portsentry.history
Merci au tuto https://www.nicolashug.dev/post/utiliser-portsentry-bloquer-scans-de-ports/
Pages: 1 2
Après un petit contrôle des IP bannies par portsentry, il s’avère que 95% sont des tentatives de connexion au port SSH 22, qui n’est pas utilisé par mon serveur (puisque paramétré sur un autre port que le port standard SSH).
Bonjour,
chez moi il y a déjà un fichier /etc/fail2ban/filter.d/portsentry.conf (Debian Bullseye) avec le contenu suivant, on dirait que çà n’a rien à voir ! :
# Fail2Ban filter for failure attempts in Counter Strike-1.6
#
#
[Definition]
failregex = \/ Port\: [0-9]+ (TCP|UDP) Blocked$
ignoreregex =
datepattern = {^LN-BEG}Epoch
{^LN-BEG}
# Author: Pacop
Je n’avais pas ce fichier (debian Buster): le tien regarde le log général que regarde fail2ban.
Etrange quand même la première ligne du fichier:
# Fail2Ban filter for failure attempts in Counter Strike-1.6Donc à tester si elle fonctionne, mais si c’est le cas c’est une solution plus propre que la mienne, car de mon coté, j’ai construit avec mes connaissances (je ne suis pas un pro de linux): Pas besoin de faire appel à une commande externe dans portsentry (et donc de créer le fichier script correspondant).
J’en prend note pour ma prochaine installation, merci.
Je déterre un peu le sujet, mais une question me taraude, si j’active la jail ci-dessus (présente également dans mes fichiers de conf sous Debian Buster) je dois commenter la ligne : KILL_RUN_CMD= »/home/unutilisateur/portsentry_ext_cmd.sh $TARGET$ » dans le fichier de conf de portsentry et remettre
BLOCK_UDP= »1″
BLOCK_TCP= »1″
pour laisser fail2ban ban l’ip?
Si on veut laisser fail2ban faire le travail, ne faut-il pas laisser
BLOCK_UDP=”0″
BLOCK_TCP=”0″
La conf de blockage se trouve sur fail2ban. Ici on ne devrait que demander les logs, non?
Oui, comme tu le dis, « Si on veut laisser fail2ban faire le travail ».
L’avantage (et aussi inconvénient) de laisser ces deux paramètres à 1 est que portsentry fera aussi le ban, mais lui tant que la cession est ouverte, donc un ban en double.
De plus, portsentry fait un ban dans les deux sens (réception et envoi) alors que fail2ban ne le fait qu’en réception.
Oui, çà devrait fonctionner.