Fail2Ban et reverse ip

Support Debian
#21

comment puis-je donc faire pour bloquer cette ip sur tout les ports ?

#22

Salut,

Il doit être possible de faire un filtre anti “port scanner” avec fail2ban.
Je pense qu’il suffit de préciser port = all

Je n’ai jamais essayé, mon port ssh n’est jamais touché, ils sont bloqués avant par portsentry.

J’ai trouvé ça sur le net, jamais essayé, sans garantie.
Si ça fonctionne, merci de donner un retour:

[code][portscan]

enabled = true
port = all
banaction = iptables-allports
filter = portscan
logpath = /var/log/iptables.log
maxrety = 1
findtime = 100
bantime = 40000[/code]

[code]
[Definition]
failregex = .IN=eth0. SRC= (DST=.PROTO=TCP SPT=. DPT=21 WINDOW=.|DST=.PROTO=TCP SPT=. DPT=22 WINDOW=.|DST=.PROTO=TCP SPT=. DPT=23 WINDOW=.|DST=.PROTO=TCP SPT=. DPT=25 WINDOW=.)

ignoreregex =[/code]

A toi de régler le failregex à ton gout.

#23

En te lisant je me suis rendu compte qu’il suffisait que je réfléchisse un peu …
remplacer iptables-multiports par iptables-allports
ceci résout le problème du port non correspondant dans le jail.conf
l’ip est donc bien bannie sur tout les port comme souhaiter
Merci beaucoup a vous pour votre aide et j’aurais appris quelques petites choses ce soir.

Edit : mettre le port à all ne fonctionne pas si tu laisse banaction sur iptables-multiports
dans le cas ou tu te met banaction sur iptables-allports il n’est même plus nécessaire de spécifier le port

#24

Syam a fait les réponses que j’aurais faites.
En plus de ça, je te propose de faire :

Authentication:

LoginGraceTime 120
PermitRootLogin yes ==> no
StrictModes yes
.
.
.

Change to no to disable tunnelled clear text passwords

#PasswordAuthentication yes … si tu emploies des clefs comme indiqué non commenté plus haut, décommenter cette ligne et de remplacer ‘yes’ par ‘no’. Même si ça semble avoir un effet identique, c’est plus impératif.
RSAAuthentication yes
PubkeyAuthentication yes

Sinon, commente les deux lignes en vert.

#25

Salut,

Si c’est résolu, n’oublie pas la coche verte pour le signaler.

Je n’ai toujours pas compris ton histoire de reverse ip… :017

#26

Pas compliqué pourtant. iptables -L affiche le reverse des adresses IP figurant dans les règles, aussi l’OP pensait à tort qu’iptables avait enregistré le reverse et non l’adresse et que c’est pour cette raison qu’il ne bloquait pas les connexions depuis cette adresse.

#27

Salut,

Ben justement, c’est ça que je n’arrive pas à comprendre… je ne vois aucun reverse. :017

iptables -L ACCEPT icmp -- 176.31.249.250 anywhere

iptables - S -A INPUT -s 176.31.249.250/32 -i eth0 -p icmp -j ACCEPT

iptables-save A INPUT -s 176.31.249.250/32 -i eth0 -p icmp -j ACCEPT

#28

Peut-être parce que 176.31.249.250 n’a pas de reverse défini ?

#29

Pour ce qui est du reverse ip lorsque je fait iptables -L ce sont les reverse qui ressortent comme étant bannie
je pensais a l’origine que c’était a cause de sa que fail2ban été inefficace mais non :unamused:

lorsque je fait un iptables -L :

Chain fail2ban-ssh (1 references) target prot opt source destination DROP all -- AAmiens-156-1-28-226.w90-18.abo.wanadoo.fr anywhere

#30

Ok, je viens de regarder en détail, et effectivement certaines sont bien les “reverses” d’IP bannies.
Merci.