subject:"Re\: Fail2ban"

Re: fail2ban regex

2020-05-05 Par sujet G2PC



> > Un outil de bannissement « définitif » pour ceux qui insistent
> > lourdement « multiban » répétés, basé sur l’analyse des logs de
> > Fail2ban. Vous pouvez le trouver sur l’URL suivante :
> >
> https://www.cybernaute.ch/bannir-definitivement-ip-bannies-frequemment-fail2ban/
>
> >  Mais cela ne suffisant pas car les réseaux servant à beaucoup
> > d’attaques permettent le changement d’IP, nous ajoutons des règles
> > « ipset » nourries par des RBL qui bloquent même certains réseaux
> > connus pour leurs pratiques douteuses. La solution simple est basée
> > sur 3 ou 4 sites (https://blognote32.net/iptables-ip-blacklist/)
> > Vous pouvez aussi aller voir sur
> > https://iplists.firehol.org/#aboutCollapseThree…
>
>
>     Intéressant. Je note pour plus tard.
+1

Re: fail2ban regex

2020-05-01 Par sujet BERTRAND Joël

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Pierre Malard a écrit :
> Bonjour,

Bonjour,

> Je ne sais pas si cela correspond à ce que vous cherchez mais ici
> pour les serveurs sensibles nous nous appuyons en complément de
> Fail2ban qui ne banni que les IP de façon temporaires 2 ajouts :
> 
> Un outil de bannissement « définitif » pour ceux qui insistent
> lourdement « multiban » répétés, basé sur l’analyse des logs de
> Fail2ban. Vous pouvez le trouver sur l’URL suivante : 
> https://www.cybernaute.ch/bannir-definitivement-ip-bannies-frequemment-fail2ban/
>
>  Mais cela ne suffisant pas car les réseaux servant à beaucoup
> d’attaques permettent le changement d’IP, nous ajoutons des règles
> « ipset » nourries par des RBL qui bloquent même certains réseaux
> connus pour leurs pratiques douteuses. La solution simple est basée
> sur 3 ou 4 sites (https://blognote32.net/iptables-ip-blacklist/) 
> Vous pouvez aussi aller voir sur
> https://iplists.firehol.org/#aboutCollapseThree…
> 

Intéressant. Je note pour plus tard.

Bien cordialement,

JKB
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEq4YCoAJMwLElZVYXOAfo0lKQ8+cFAl6r2Q0ACgkQOAfo0lKQ
8+dImA//UlvrQCwLd6j3FCkyXd1p/bbXeyUGltac1A6s30m6BKe1w4LADAapglvY
kJpB+eAG8gG5li9+A4ixZlwF6v21mb8oL6PieaJ70R7ZLztvxjtp0gGPYnYpibie
ZRiB5Mz/EGO8ntYKpk45FtxcITh815ZVm05p5tcGzf0qusrAxRHdb5pTEstpd0ZY
iQdNi3uCETuqrwA3uxQ80lWtnoIeMbDl4YnCqD1owaInb0jyEg8J0kYvGSZvNDxE
EBRTY72Gr47eQisOo5rUUAbXMNGWVHtVqK1VWBU6lAWggEuFgEJqw+eYRykporJz
PEc78BIubRSsolafBQaOi9DaBBD9vJ5Nnv5C1s4IYhTnewFVi+eTuElu9ZvuTAEL
vTqcH7Tqd0o0KFh8cVzLKvnvw8gWyM7bXO+XJ2QxEndly3zIvGesGnubFtqHPAL+
8vaSYFxc6M9dqvqucpSRC9+ymv6D3hO/tc9UhWuqL5FO9CLnIECzPLIInA9XFxLq
l4oU1WaChZQmhd3vhaK8HLjJ1pzHZM3bn3KZcGO8PdShV+Ry+y5RPtWRktB2v9ds
EY5BtpHszSZ2juuK9SMo9bgLXCBIBGc3yBDNalLW9qVhnasCdBCSgGqhD1w/tku5
1ASZtXFFISitF/ekyh7Y9K4iYCpxdOxYsIqYxKKSRjNFtT/RVLM=
=nu0z
-END PGP SIGNATURE-

Re: fail2ban regex

2020-05-01 Par sujet BERTRAND Joël

Charles Plessy a écrit :
> Le Thu, Apr 30, 2020 at 12:01:36PM +0200, BERTRAND Joël a écrit :
>>
>>  Parce que le type est borné, que ça fait des jours que ça dure et que
>> l'IP change régulièrement. Par ailleurs, fail2ban est fait pour cela et
>> j'ai autre chose à faire que de surveiller /var/log/syslog.
> 
> Bonjour Joël,
> 
> as-tu essayé la cellule "récidive" de fail2ban ?
> 
> Amicalement,

Bonjour,

Oui, naturellement. Sauf que dans mon cas, ça ne fonctionne pas parce
que le filtre sur TLS ne fonctionne pas.

Aujourd'hui, mon filtre est le suivant :
_daemon = (?:courier)?(?:imapd?|pop3d?)-ssl?

failregex = ^%(__prefix_line)s.*ip=\[\], An unexpected TLS packet
was received.$

qui ne fonctionne pas. La partie failregex toute seule donne quelque
chose si je retire "^%(__prefix_line)s.*" :


fail2ban-regex /var/log/syslog "ip=\[\], An unexpected TLS packet
was received.$"
...
Lines: 73005 lines, 0 ignored, 6 matched, 72999 missed
[processed in 2.80 sec]

Mais fail2ban rajoute une en-tête :fail2ban-client get courier-tls failregex
The following regular expression are defined:
`- [0]:
ip=\[(?:(?:::f{4,6}:)?(?P(?:\d{1,3}\.){3}\d{1,3})|\[?(?P(?:[0-9a-fA-F]{1,4}::?|::){1,7}(?:[0-9a-fA-F]{1,4}|(?<=:):))\]?|(?P[\w\-.^_]*\w))\],
An unexpected TLS packet was received.$
et là, ça ne fonctionne plus.

Mais sans le retrait de ^%(__prefix_line)s.*, cela ne donne strictement
rien :

Root rayleigh:[/var/lib/iptables] > fail2ban-client get courier-tls
failregex
The following regular expression are defined:
`- [0]: ^(?:\[\])?\s*(?:<[^.]+\.[^.]+>\s+)?(?:\S+\s+)?(?:kernel: \[
*\d+\.\d+\]\s+)?(?:@vserver_\S+\s+)?(?:(?:(?:\[\d+\])?:\s+[\[\(]?(?:courier)?(?:imapd?|pop3d?)-ssl?(?:\(\S+\))?[\]\)]?:?|[\[\(]?(?:courier)?(?:imapd?|pop3d?)-ssl?(?:\(\S+\))?[\]\)]?:?(?:\[\d+\])?:?)\s+)?(?:\[ID
\d+
\S+\]\s+)?.*ip=\[(?:(?:::f{4,6}:)?(?P(?:\d{1,3}\.){3}\d{1,3})|\[?(?P(?:[0-9a-fA-F]{1,4}::?|::){1,7}(?:[0-9a-fA-F]{1,4}|(?<=:):))\]?|(?P[\w\-.^_]*\w))\],
An unexpected TLS packet was received.$
Root rayleigh:[/var/lib/iptables] > fail2ban-regex /var/log/syslog "[0]:
^(?:\[\])?\s*(?:<[^.]+\.[^.]+>\s+)?(?:\S+\s+)?(?:kernel: \[
*\d+\.\d+\]\s+)?(?:@vserver_\S+\s+)?(?:(?:(?:\[\d+\])?:\s+[\[\(]?(?:courier)?(?:imapd?|pop3d?)-ssl?(?:\(\S+\))?[\]\)]?:?|[\[\(]?(?:courier)?(?:imapd?|pop3d?)-ssl?(?:\(\S+\))?[\]\)]?:?(?:\[\d+\])?:?)\s+)?(?:\[ID
\d+
\S+\]\s+)?.*ip=\[(?:(?:::f{4,6}:)?(?P(?:\d{1,3}\.){3}\d{1,3})|\[?(?P(?:[0-9a-fA-F]{1,4}::?|::){1,7}(?:[0-9a-fA-F]{1,4}|(?<=:):))\]?|(?P[\w\-.^_]*\w))\],
An unexpected TLS packet was received.$"

Running tests
=

Use   failregex line : [0]: ^(?:\[\])?\s*(?:<[^.]+\.[^.]+>\s+)?(?:\S+\s+)...
Use log file : /var/log/syslog
Use encoding : UTF-8


Results
===

Failregex: 0 total

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [72942] {^LN-BEG}(?:DAY )?MON Day
%k:Minute:Second(?:\.Microseconds)?(?: ExYear)?
`-

Lines: 72942 lines, 0 ignored, 0 matched, 72942 missed
[processed in 2.80 sec]

Missed line(s): too many to print.  Use --print-all-missed to print all
72942 lines

Re: fail2ban regex

2020-05-01 Par sujet Charles Plessy

Le Thu, Apr 30, 2020 at 12:01:36PM +0200, BERTRAND Joël a écrit :
> 
>   Parce que le type est borné, que ça fait des jours que ça dure et que
> l'IP change régulièrement. Par ailleurs, fail2ban est fait pour cela et
> j'ai autre chose à faire que de surveiller /var/log/syslog.

Bonjour Joël,

as-tu essayé la cellule "récidive" de fail2ban ?

Amicalement,

-- 
Charles Plessy
Akano, Uruma, Okinawa, Japan

Re: fail2ban regex

2020-04-30 Par sujet Pierre Malard

Bonjour,

Je ne sais pas si cela correspond à ce que vous cherchez mais ici pour
les serveurs sensibles nous nous appuyons en complément de Fail2ban qui
ne banni que les IP de façon temporaires 2 ajouts :

Un outil de bannissement « définitif » pour ceux qui insistent lourdement
« multiban » répétés, basé sur l’analyse des logs de Fail2ban. Vous
pouvez le trouver sur l’URL suivante :

https://www.cybernaute.ch/bannir-definitivement-ip-bannies-frequemment-fail2ban/

Mais cela ne suffisant pas car les réseaux servant à beaucoup d’attaques
permettent le changement d’IP, nous ajoutons des règles « ipset » nourries
par des RBL qui bloquent même certains réseaux connus pour leurs pratiques 
douteuses.
La solution simple est basée sur 3 ou 4 sites 
(https://blognote32.net/iptables-ip-blacklist/)
Vous pouvez aussi aller voir sur 
https://iplists.firehol.org/#aboutCollapseThree…

Cordialement


> Le 30 avr. 2020 à 12:01, BERTRAND Joël  a écrit :
> 
> Nisar JAGABAR a écrit :
>> 
>> Et pourquoi ne pas bannir manuellement cette IP ? fail2ban-client te
>> permets de le faire, regarde la sortie de 'fail2ban-client --help' ou
>> son man :
>> bash# fail2ban-client set  banip 
>> 
>> Pour le nom du JAIL, tu as une liste de ceux déjà configuré avec un
>> bash# fail2ban-client status
>> 
>> Pour les IP déjà bannis sur un JAIL particulier :
>> bash# fail2ban-client status 
> 
>   Parce que le type est borné, que ça fait des jours que ça dure et que
> l'IP change régulièrement. Par ailleurs, fail2ban est fait pour cela et
> j'ai autre chose à faire que de surveiller /var/log/syslog.
> 
>   JKB
> 

--
Pierre Malard

  « on ne risque rien à livrer le secret professionnel car
 on ne livre pas la façon de s’en servir »
  Jean Cocteau - « Le secret professionnel » - 1922

   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: fail2ban regex

2020-04-30 Par sujet BERTRAND Joël

Nisar JAGABAR a écrit :
> 
> Et pourquoi ne pas bannir manuellement cette IP ? fail2ban-client te
> permets de le faire, regarde la sortie de 'fail2ban-client --help' ou
> son man :
> bash# fail2ban-client set  banip 
> 
> Pour le nom du JAIL, tu as une liste de ceux déjà configuré avec un
> bash# fail2ban-client status
> 
> Pour les IP déjà bannis sur un JAIL particulier :
> bash# fail2ban-client status 

Parce que le type est borné, que ça fait des jours que ça dure et que
l'IP change régulièrement. Par ailleurs, fail2ban est fait pour cela et
j'ai autre chose à faire que de surveiller /var/log/syslog.

JKB

Re: fail2ban regex

2020-04-30 Par sujet Nisar JAGABAR




Et pourquoi ne pas bannir manuellement cette IP ? fail2ban-client te 
permets de le faire, regarde la sortie de 'fail2ban-client --help' ou 
son man :

bash# fail2ban-client set  banip 

Pour le nom du JAIL, tu as une liste de ceux déjà configuré avec un
bash# fail2ban-client status

Pour les IP déjà bannis sur un JAIL particulier :
bash# fail2ban-client status 


Le 29/04/2020 à 10:09, BERTRAND Joël a écrit :

Bonjour à tous,

Depuis plus de 48 heures, je subis une attaque sur l'un de mes serveurs
de mails en provenance de Russie. Les logs sont plein de ce genre de chose :

Apr 29 10:06:33 rayleigh pop3d-ssl: ip=[:::213.217.0.213], An
unexpected TLS packet was received.
Apr 29 10:06:33 rayleigh pop3d-ssl: Disconnected, ip=[:::213.217.0.213]

Et ça défile à une vitesse délirante. Je tente donc de rajouter une
règle fail2ban mais elle ne fait rien.

J'ai rajouté courier-tls.conf:

[INCLUDES]
before = common.conf

[Definition]
_daemon = (imapd-ssl|pop3d-ssl)?
failregex = ^.*ip=\[\], An unexpected TLS packet was received.$
ignoreregex =
datepattern = {^LN-BEG}

J'ai naturellement modifié le fichier de configuration de fail2ban et
cette règle est chargée :

2020-04-29 10:05:04,148 fail2ban.server [1114037]: INFO
Reload jail 'courier-tls'
2020-04-29 10:05:04,148 fail2ban.filter [1114037]: INFO
encoding: UTF-8
2020-04-29 10:05:04,148 fail2ban.filter [1114037]: INFO
maxRetry: 5
2020-04-29 10:05:04,148 fail2ban.filter [1114037]: INFO
findtime: 600
2020-04-29 10:05:04,148 fail2ban.actions[1114037]: INFO
banTime: 600

Mais elle ne fait rien. Si je la teste avec fail2ban-regex, elle semble
toutefois fonctionner. Où donc ai-je fait une boulette ?

Bien cordialement,

JKB



--
Nisar JAGABAR
 ,= ,-_-. =.
((_/)o o(\_))
 `-'(. .)`-'
 \_/

Re: fail2ban regex

2020-04-29 Par sujet BERTRAND Joël

Lorsque j'interroge directement la regex, j'obtiens ceci :

Root rayleigh:[/etc/fail2ban/filter.d] > fail2ban-client get courier-tls
failregex
The following regular expression are defined:
`- [0]:
^.*ip=\[(?:(?:::f{4,6}:)?(?P(?:\d{1,3}\.){3}\d{1,3})|\[?(?P(?:[0-9a-fA-F]{1,4}::?|::){1,7}(?:[0-9a-fA-F]{1,4}|(?<=:):))\]?|(?P[\w\-.^_]*\w))\],
An unexpected TLS packet was received.$

J'avoue que je ne sais pas interpréter.

Bien cordialement,

JKB

Re: fail2ban regex

2020-04-29 Par sujet G2PC



> Je n'en sais rien et c'est piégeux.

-> https://github.com/fail2ban/fail2ban/issues

Re: fail2ban regex

2020-04-29 Par sujet BERTRAND Joël

NoSpam a écrit :
> 
> Le 29/04/2020 à 11:39, BERTRAND Joël a écrit :
>> NoSpam a écrit :
>>> Le 29/04/2020 à 11:07, BERTRAND Joël a écrit :
 NoSpam a écrit :
> Le 29/04/2020 à 10:09, BERTRAND Joël a écrit :
>>  Bonjour à tous,
> Bonjour
>
> la version de fail2ban prend t'elle en charge ipv6 (version minimum
> 0.10) ?
 Oui : 0.10.2-2.1.

 Mais mon installation fail2ban traitait IPv6 depuis très longtemps
 grâce à un petit patch bien senti ;-)

 Par ailleurs, l'adresse IP en question est une IPv4.
>>> Non, c'est une IPv6 (ipv4-mapped ipv6)
>>  Ben non. courier indique les adresses IPv4 comme ça. De toute façon, je
>> ne retrouve pas l'IP dans la chaîne correspondante de ip6tables.
> 
> Si si j'insiste ;)
> 
> https://en.wikipedia.org/wiki/IPv6
> 
> Hybrid dual-stack IPv6/IPv4 implementations recognize a special class of
> addresses, the IPv4-mapped IPv6 addresses. These addresses are typically
> written with a 96-bit prefix in the standard IPv6 format, and the
> remaining 32 bits written in the customary dot-decimal notation
>  of IPv4.
> 
> Addresses in this group consist of an 80-bit prefix of zeros, the next
> 16 bits are ones, and the remaining, least-significant 32 bits contain
> the IPv4 address. For example, :::192.0.2.128 represents the IPv4
> address 192.0.2.128
> 
> J'utilise cette numérotation pour les règles firewall afin de pouvoir
> récupérer une connexion ipv6 si l'adresse global venait à défaillir.

Sauf que non. C'est juste un affichage par courier. La connexion est
une connexion réelle IPv4 et pas IPv4 mappée en IPv6.

Preuve :Apr 29 12:13:46 rayleigh pop3d-ssl: ip=[:::213.217.0.213],
An unexpected TLS packet was received.
Apr 29 12:13:46 rayleigh pop3d-ssl: Disconnected, ip=[:::213.217.0.213]
Apr 29 12:13:48 rayleigh pop3d-ssl: Connection, ip=[:::213.217.0.213]
Apr 29 12:13:48 rayleigh pop3d-ssl: ip=[:::213.217.0.213], An
unexpected TLS packet was received.
Apr 29 12:13:48 rayleigh pop3d-ssl: Disconnected, ip=[:::213.217.0.213]
Apr 29 12:13:49 rayleigh pop3d-ssl: Connection, ip=[:::213.217.0.213]
Apr 29 12:13:49 rayleigh pop3d-ssl: ip=[:::213.217.0.213], An
unexpected TLS packet was received.
Apr 29 12:13:49 rayleigh pop3d-ssl: Disconnected, ip=[:::213.217.0.213]
Apr 29 12:13:51 rayleigh pop3d-ssl: Connection, ip=[:::213.217.0.213]
Apr 29 12:13:51 rayleigh pop3d-ssl: ip=[:::213.217.0.213], An
unexpected TLS packet was received.
Apr 29 12:13:51 rayleigh pop3d-ssl: Disconnected, ip=[:::213.217.0.213]

Et un coup de tcpdump :
12:13:41.213604 IP 213.217.0.213.47835 > rayleigh.systella.fr.pop3s:
Flags [.], ack 2478110317, win 258, length 0
12:13:41.214758 IP 213.217.0.213.47835 > rayleigh.systella.fr.pop3s:
Flags [P.], seq 0:43, ack 1, win 258, length 43
12:13:41.214812 IP rayleigh.systella.fr.pop3s > 213.217.0.213.47835:
Flags [.], ack 43, win 256, length 0
12:13:41.246767 IP rayleigh.systella.fr.pop3s > 213.217.0.213.47835:
Flags [P.], seq 1:8, ack 43, win 256, length 7
12:13:41.247583 IP rayleigh.systella.fr.pop3s > 213.217.0.213.47835:
Flags [R.], seq 8, ack 43, win 256, length 0

Maintenant, ne me demande pas pourquoi courier utilise cette notation,
je n'en sais rien et c'est piégeux.

JKB

Re: fail2ban regex

2020-04-29 Par sujet BERTRAND Joël

G2PC a écrit :
> 
>> J'ai naturellement modifié le fichier de configuration de fail2ban et
>> cette règle est chargée.
> 
> 
> Si ta règle match des résultats dans les logs, je suppose que la règle
> est correcte !
> Logique ?

Il me semble. Le doute que j'ai est sur

_daemon = (?:imapd-ssl|pop3d-ssl)

Les regex python sont vraiment des trucs cabalistiques.

> Par contre, personnellement, je me trompe peut être, j'ai peu confiance
> en la commande reload.
> 
> 
> Si tu redémarres totalement Fail2ban, que ce passerait t'il ?
> sudo service fail2ban restart
> 

J'ai essayé les deux, même motif, même punition.

> N'aurais tu pas, par hasard, une panne au démarrage, si tu consultais
> alors les logs en direct de Fail2ban, qui t'indiquerait que Fail2ban n'a
> pas redémarré, pour X ou Y raison ?
> tail -f -n 30 /var/log/fail2ban.log

Tout semble fonctionnel côté fail2ban, les logs donnent :

2020-04-29 12:09:45,750 fail2ban.jail   [1214575]: INFOJail
'sshd' started
2020-04-29 12:09:45,751 fail2ban.jail   [1214575]: INFOJail
'apache-auth' started
2020-04-29 12:09:45,751 fail2ban.jail   [1214575]: INFOJail
'roundcube-auth' started
2020-04-29 12:09:45,752 fail2ban.jail   [1214575]: INFOJail
'sendmail-auth' started
2020-04-29 12:09:45,753 fail2ban.jail   [1214575]: INFOJail
'sendmail-reject' started
2020-04-29 12:09:45,754 fail2ban.jail   [1214575]: INFOJail
'courier-auth' started
2020-04-29 12:09:45,755 fail2ban.jail   [1214575]: INFOJail
'mysqld-auth' started
2020-04-29 12:09:45,756 fail2ban.jail   [1214575]: INFOJail
'zoneminder' started
2020-04-29 12:09:45,757 fail2ban.jail   [1214575]: INFOJail
'courier-tls' started

> Si tu arrives à résoudre ce problème, j'aimerais bien pouvoir ajouter ta
> règle, à mon tutoriel, n'hésite pas à redonner la règle fonctionnelle,
> par la suite. ( Prison + Filtre )
> Installer et utiliser Fail2ban :
> https://wiki.visionduweb.fr/index.php?title=Installer_et_utiliser_Fail2ban

Si j'y arrive ;-)

JKB

Re: fail2ban regex

2020-04-29 Par sujet NoSpam



Le 29/04/2020 à 11:39, BERTRAND Joël a écrit :

NoSpam a écrit :

Le 29/04/2020 à 11:07, BERTRAND Joël a écrit :

NoSpam a écrit :

Le 29/04/2020 à 10:09, BERTRAND Joël a écrit :

  Bonjour à tous,

Bonjour

la version de fail2ban prend t'elle en charge ipv6 (version minimum
0.10) ?

 Oui : 0.10.2-2.1.

 Mais mon installation fail2ban traitait IPv6 depuis très longtemps
grâce à un petit patch bien senti ;-)

 Par ailleurs, l'adresse IP en question est une IPv4.

Non, c'est une IPv6 (ipv4-mapped ipv6)

Ben non. courier indique les adresses IPv4 comme ça. De toute façon, je
ne retrouve pas l'IP dans la chaîne correspondante de ip6tables.


Si si j'insiste ;)

https://en.wikipedia.org/wiki/IPv6

Hybrid dual-stack IPv6/IPv4 implementations recognize a special class of 
addresses, the IPv4-mapped IPv6 addresses. These addresses are typically 
written with a 96-bit prefix in the standard IPv6 format, and the 
remaining 32 bits written in the customary dot-decimal notation 
 of IPv4.


Addresses in this group consist of an 80-bit prefix of zeros, the next 
16 bits are ones, and the remaining, least-significant 32 bits contain 
the IPv4 address. For example, :::192.0.2.128 represents the IPv4 
address 192.0.2.128


J'utilise cette numérotation pour les règles firewall afin de pouvoir 
récupérer une connexion ipv6 si l'adresse global venait à défaillir.

Re: fail2ban regex

2020-04-29 Par sujet G2PC



> J'ai naturellement modifié le fichier de configuration de fail2ban et
> cette règle est chargée.


Si ta règle match des résultats dans les logs, je suppose que la règle
est correcte !
Logique ?

Par contre, personnellement, je me trompe peut être, j'ai peu confiance
en la commande reload.


Si tu redémarres totalement Fail2ban, que ce passerait t'il ?
sudo service fail2ban restart


N'aurais tu pas, par hasard, une panne au démarrage, si tu consultais
alors les logs en direct de Fail2ban, qui t'indiquerait que Fail2ban n'a
pas redémarré, pour X ou Y raison ?
tail -f -n 30 /var/log/fail2ban.log


Si tu arrives à résoudre ce problème, j'aimerais bien pouvoir ajouter ta
règle, à mon tutoriel, n'hésite pas à redonner la règle fonctionnelle,
par la suite. ( Prison + Filtre )
Installer et utiliser Fail2ban :
https://wiki.visionduweb.fr/index.php?title=Installer_et_utiliser_Fail2ban

Re: fail2ban regex

2020-04-29 Par sujet BERTRAND Joël

NoSpam a écrit :
> 
> Le 29/04/2020 à 11:07, BERTRAND Joël a écrit :
>> NoSpam a écrit :
>>> Le 29/04/2020 à 10:09, BERTRAND Joël a écrit :
  Bonjour à tous,
>>> Bonjour
>>>
>>> la version de fail2ban prend t'elle en charge ipv6 (version minimum
>>> 0.10) ?
>> Oui : 0.10.2-2.1.
>>
>> Mais mon installation fail2ban traitait IPv6 depuis très longtemps
>> grâce à un petit patch bien senti ;-)
>>
>> Par ailleurs, l'adresse IP en question est une IPv4.
> Non, c'est une IPv6 (ipv4-mapped ipv6)

Ben non. courier indique les adresses IPv4 comme ça. De toute façon, je
ne retrouve pas l'IP dans la chaîne correspondante de ip6tables.

JKB

Re: fail2ban regex

2020-04-29 Par sujet NoSpam




Le 29/04/2020 à 11:07, BERTRAND Joël a écrit :

NoSpam a écrit :

Le 29/04/2020 à 10:09, BERTRAND Joël a écrit :

 Bonjour à tous,

Bonjour

la version de fail2ban prend t'elle en charge ipv6 (version minimum 0.10) ?

Oui : 0.10.2-2.1.

Mais mon installation fail2ban traitait IPv6 depuis très longtemps
grâce à un petit patch bien senti ;-)

Par ailleurs, l'adresse IP en question est une IPv4.

Non, c'est une IPv6 (ipv4-mapped ipv6)

Re: fail2ban regex

2020-04-29 Par sujet BERTRAND Joël

NoSpam a écrit :
> 
> Le 29/04/2020 à 10:09, BERTRAND Joël a écrit :
>> Bonjour à tous,
> 
> Bonjour
> 
> la version de fail2ban prend t'elle en charge ipv6 (version minimum 0.10) ?

Oui : 0.10.2-2.1.

Mais mon installation fail2ban traitait IPv6 depuis très longtemps
grâce à un petit patch bien senti ;-)

Par ailleurs, l'adresse IP en question est une IPv4.

JKB

Re: fail2ban regex

2020-04-29 Par sujet NoSpam




Le 29/04/2020 à 10:09, BERTRAND Joël a écrit :

Bonjour à tous,


Bonjour

la version de fail2ban prend t'elle en charge ipv6 (version minimum 0.10) ?



Depuis plus de 48 heures, je subis une attaque sur l'un de mes serveurs
de mails en provenance de Russie. Les logs sont plein de ce genre de chose :

Apr 29 10:06:33 rayleigh pop3d-ssl: ip=[:::213.217.0.213], An
unexpected TLS packet was received.
Apr 29 10:06:33 rayleigh pop3d-ssl: Disconnected, ip=[:::213.217.0.213]

Et ça défile à une vitesse délirante. Je tente donc de rajouter une
règle fail2ban mais elle ne fait rien.

J'ai rajouté courier-tls.conf:

[INCLUDES]
before = common.conf

[Definition]
_daemon = (imapd-ssl|pop3d-ssl)?
failregex = ^.*ip=\[\], An unexpected TLS packet was received.$
ignoreregex =
datepattern = {^LN-BEG}

J'ai naturellement modifié le fichier de configuration de fail2ban et
cette règle est chargée :

2020-04-29 10:05:04,148 fail2ban.server [1114037]: INFO
Reload jail 'courier-tls'
2020-04-29 10:05:04,148 fail2ban.filter [1114037]: INFO
encoding: UTF-8
2020-04-29 10:05:04,148 fail2ban.filter [1114037]: INFO
maxRetry: 5
2020-04-29 10:05:04,148 fail2ban.filter [1114037]: INFO
findtime: 600
2020-04-29 10:05:04,148 fail2ban.actions[1114037]: INFO
banTime: 600

Mais elle ne fait rien. Si je la teste avec fail2ban-regex, elle semble
toutefois fonctionner. Où donc ai-je fait une boulette ?

Bien cordialement,

JKB

Re: fail2ban : sshd jail ne fonctionne pas (encore)

2019-07-11 Par sujet Pierre Malard

Ok, logique.

Regarde quand même le /var/log/syslog quand tu démarre Fail2Ban…

> Le 11 juil. 2019 à 19:11, Belaïd  a écrit :
> 
> Salut,
> 
> Comme les serveurs sont identiques,  pourquoi ne pas mettre la config des 
> jails dans le même dossier ?  À ta place Je ferai ça dans 
> /etc/fail2ban/jail.d/
> 
> Le jeu. 11 juil. 2019 17:06, fab  > a écrit :
> salut la liste,
> 
> Soient 2 serveurs quasi-identiques sur stretch à jour. fail2ban
> fonctionne correctement sur le serveur B mais pas sur le serveur A. Pour
> l'instant je n'ai paramétré qu'une seule prison sshd.
> 
> 
> serveur A:
> # cat defaults-debian.conf
> [sshd]
> port = 
> enabled = true
> maxretry = 2
> 
> serveur B:
> # cat ../jail.local
> [sshd]
> port = 
> enabled = true
> maxretry = 2
> 
> Les /etc/ssh/ssd_confid des 2 serveurs sont identiques.
> 
> Serveur A et B:
> # iptables -S
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N f2b-sshd
> -A INPUT -p tcp -m multiport --dports  -j f2b-sshd
> -A f2b-sshd -j RETURN
> 
> 
> /var/log/fail2ban.log des Serveurs A et B sont identiques:
> 
>   Stopping all jails
>   Jail 'sshd' stopped
>   Exiting Fail2ban
>   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.6
>   Connected to fail2ban persistent database
> '/var/lib/fail2ban/fail2ban.sqlite3'
>   Creating new jail 'sshd'
>   Jail 'sshd' uses pyinotify {}
>   Initiated 'pyinotify' backend
>   Set jail log file encoding to UTF-8
>   Set maxRetry = 2
>   Added logfile = /var/log/auth.log
>   Set findtime = 600
>   Set banTime = 600
>   Set maxlines = 10
>   Jail sshd is not a JournalFilter instance
>   Jail 'sshd' started
> 
> /etc/hosts.allow sur les 2 serveurs sont les même.
> 
> Bref, c'est tout pareil (à priori).
> 
> Quand je fais un ssh toto@serveurB: et que je rentre un mauvais mot
> de passe, fail2ban me bannit: OK.
> 
> Dans le auth.log du serveur B, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 40664 ssh2
> 
> Quand je fais un ssh toto@serveurA: et que je rentre un mauvais mot
> de passe, fail2ban ne me bannit pas et je n'ai rien dans fail2ban.log.
> 
> Dans le auth.log du serveur A, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Connection closed by 11.22.33.44 port 41342 [preauth]
> PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=11.22.33.44  user=toto
> 
> Tout se passe comme si je n'avais pas démarré fail2an sur le serveur A.
> 
> Si vous avez une piste ou une idée, une vanne ou un bon mot je prends!
> 
> merki,
> 
> f.
> 
> 

--
Pierre Malard

  « on ne risque rien à livrer le secret professionnel car
 on ne livre pas la façon de s’en servir »
  Jean Cocteau - « Le secret professionnel » - 1922

   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: fail2ban : sshd jail ne fonctionne pas (encore)

2019-07-11 Par sujet Belaïd

Salut,

Comme les serveurs sont identiques,  pourquoi ne pas mettre la config des
jails dans le même dossier ?  À ta place Je ferai ça dans
/etc/fail2ban/jail.d/

Le jeu. 11 juil. 2019 17:06, fab  a écrit :

> salut la liste,
>
> Soient 2 serveurs quasi-identiques sur stretch à jour. fail2ban
> fonctionne correctement sur le serveur B mais pas sur le serveur A. Pour
> l'instant je n'ai paramétré qu'une seule prison sshd.
>
>
> serveur A:
> # cat defaults-debian.conf
> [sshd]
> port = 
> enabled = true
> maxretry = 2
>
> serveur B:
> # cat ../jail.local
> [sshd]
> port = 
> enabled = true
> maxretry = 2
>
> Les /etc/ssh/ssd_confid des 2 serveurs sont identiques.
>
> Serveur A et B:
> # iptables -S
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N f2b-sshd
> -A INPUT -p tcp -m multiport --dports  -j f2b-sshd
> -A f2b-sshd -j RETURN
>
>
> /var/log/fail2ban.log des Serveurs A et B sont identiques:
>
>   Stopping all jails
>   Jail 'sshd' stopped
>   Exiting Fail2ban
>   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.6
>   Connected to fail2ban persistent database
> '/var/lib/fail2ban/fail2ban.sqlite3'
>   Creating new jail 'sshd'
>   Jail 'sshd' uses pyinotify {}
>   Initiated 'pyinotify' backend
>   Set jail log file encoding to UTF-8
>   Set maxRetry = 2
>   Added logfile = /var/log/auth.log
>   Set findtime = 600
>   Set banTime = 600
>   Set maxlines = 10
>   Jail sshd is not a JournalFilter instance
>   Jail 'sshd' started
>
> /etc/hosts.allow sur les 2 serveurs sont les même.
>
> Bref, c'est tout pareil (à priori).
>
> Quand je fais un ssh toto@serveurB: et que je rentre un mauvais mot
> de passe, fail2ban me bannit: OK.
>
> Dans le auth.log du serveur B, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 40664 ssh2
>
> Quand je fais un ssh toto@serveurA: et que je rentre un mauvais mot
> de passe, fail2ban ne me bannit pas et je n'ai rien dans fail2ban.log.
>
> Dans le auth.log du serveur A, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Connection closed by 11.22.33.44 port 41342 [preauth]
> PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=11.22.33.44  user=toto
>
> Tout se passe comme si je n'avais pas démarré fail2an sur le serveur A.
>
> Si vous avez une piste ou une idée, une vanne ou un bon mot je prends!
>
> merki,
>
> f.
>
>
>

Re: fail2ban : sshd jail ne fonctionne pas (encore)

2019-07-11 Par sujet Pierre Malard

Salut,

En supposant bien entendu que tu as installé le paquet Fail2Ban de Debian et 
pas un source venant du site du développeur…

Ça n’a peut-être rien à voir mais « Fail2Ban » préfère maintenant la 
déclaration des déclarations de taules (« jail ») dans un répertoire spécifique 
(« /etc/fail2ban/jail.d »). SI tu as déclaré une configuration dans le 
/etc/fail2ban/jail.local et qu’il en existe une spécifique à SSH dans le 
/etc/fail2ban/jail.d/, je ne sais pas lequel « aura raison ».

Une autre piste pour suivre le lancement de Fail2Ban c’est de suivre son 
lancement dans le fichier log /var/log/syslog. Avant de voir le comportement 
une fois lancé, il est bon de savoir s’il n’y a pas eu un problème … au 
lancement. C’est là que le lancement est suivit. Avant de voir le comportement 
une fois lancé, il est bon de savoir s’il n’y a pas eu un problème … au 
lancement.
À ce jeu, je me suis rendu compte que certains services n’écrivent pas par 
défaut leurs logs dans les fichiers déclarés par défaut dans Fail2Ban. Tout ça 
se trouve dans les fichiers « /etc/fail2ban/path-….conf ».

Sinon, pour savoir si Fail2Ban tourne, un simple :
# ps -ef | grep fail2ban
suffit.

> Le 11 juil. 2019 à 17:06, fab  a écrit :
> 
> salut la liste,
> 
> Soient 2 serveurs quasi-identiques sur stretch à jour. fail2ban
> fonctionne correctement sur le serveur B mais pas sur le serveur A. Pour 
> l'instant je n'ai paramétré qu'une seule prison sshd.
> 
> 
> serveur A:
> # cat defaults-debian.conf
> [sshd]
> port = 
> enabled = true
> maxretry = 2
> 
> serveur B:
> # cat ../jail.local
> [sshd]
> port = 
> enabled = true
> maxretry = 2
> 
> Les /etc/ssh/ssd_confid des 2 serveurs sont identiques.
> 
> Serveur A et B:
> # iptables -S
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N f2b-sshd
> -A INPUT -p tcp -m multiport --dports  -j f2b-sshd
> -A f2b-sshd -j RETURN
> 
> 
> /var/log/fail2ban.log des Serveurs A et B sont identiques:
> 
> Stopping all jails
> Jail 'sshd' stopped
> Exiting Fail2ban
> Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.6
> Connected to fail2ban persistent database
> '/var/lib/fail2ban/fail2ban.sqlite3'
> Creating new jail 'sshd'
> Jail 'sshd' uses pyinotify {}
> Initiated 'pyinotify' backend
> Set jail log file encoding to UTF-8
> Set maxRetry = 2
> Added logfile = /var/log/auth.log
> Set findtime = 600
> Set banTime = 600
> Set maxlines = 10
> Jail sshd is not a JournalFilter instance
> Jail 'sshd' started
> 
> /etc/hosts.allow sur les 2 serveurs sont les même.
> 
> Bref, c'est tout pareil (à priori).
> 
> Quand je fais un ssh toto@serveurB: et que je rentre un mauvais mot
> de passe, fail2ban me bannit: OK.
> 
> Dans le auth.log du serveur B, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 40664 ssh2
> 
> Quand je fais un ssh toto@serveurA: et que je rentre un mauvais mot
> de passe, fail2ban ne me bannit pas et je n'ai rien dans fail2ban.log.
> 
> Dans le auth.log du serveur A, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Connection closed by 11.22.33.44 port 41342 [preauth]
> PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=11.22.33.44  user=toto
> 
> Tout se passe comme si je n'avais pas démarré fail2an sur le serveur A.
> 
> Si vous avez une piste ou une idée, une vanne ou un bon mot je prends!
> 
> merki,
> 
> f.
> 
> 

--
Pierre Malard

À propos de nos chers économistes :
«Les habiles, dans notre siècle, se sont décernés a eux-mêmes la
qualification d’homme d’état. [...] ces politiques, ingénieux
a mettre aux fictions profitables un masque de nécessité.»
 Victor Hugo : “Les misérables”, La pléiade, Gallimard, P. 843

   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: Fail2ban et IMAP

2019-03-06 Par sujet Sil


Le 06/03/2019 à 08:16, Sil a écrit :

Bonjour la liste,

Depuis quelques jours quelqu'un essaie de trouver les mots de passe de 
mes comptes IMAP.


Extrait des log :
Mar  5 21:10:16 serveur authdaemond: pam_unix(imap:auth): 
authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= 
user=toto


J'ai enfin trouvé une correspondance dans mail.log :

Mar 5 21:10:18 serveur imapd-ssl: LOGIN FAILED, method=PLAIN, 
ip=[:::109.105.195.250]


Par contre fail2ban ne voit rien car son filtre est le suivant :

failregex = ^%(__prefix_line)sLOGIN FAILED, user=.*, ip=\[\]$

J'ai donc créé un nouveau jail avec le filtre suivant :

failregex = ^%(__prefix_line)sLOGIN FAILED, method=.*, ip=\[\]$

Je vais attendre un peu pour voir si le gars se représente.

Silvère

Re: fail2ban - destemail et adresses multiples

2016-05-17 Par sujet Ph. Gras


Le 17 mai 2016 à 10:15, Eric Degenetais  a écrit :

>> Je pense que ce n'est pas documenté, parce que ce n'est pas prévu
>> pour ça, on imagine mal un admin envoyer les résultats à son voisin.
> bonjour,
> moi j'imagine bien, par contre, un admin prendre des vacances, avoir
> une vie, toussa...donc il peut être intéressant qu'une ou plusieurs
> personnes agissant en backup reçoivent aussi les notifications.
> Une des solutions possibles indépendamment des possibilités de
> fail2ban lui-même serait de mettre en place une liste de diffusion et
> d'en enregistrer l'adresse.
> 
> cordialement
> 
> Eric
> 
Merkedanke a donné la réponse :

destemail = mac...@test.com bid...@test.com

Ph. Gras

Re: fail2ban - destemail et adresses multiples

2016-05-17 Par sujet Eric Degenetais

> Je pense que ce n'est pas documenté, parce que ce n'est pas prévu
> pour ça, on imagine mal un admin envoyer les résultats à son voisin.
bonjour,
moi j'imagine bien, par contre, un admin prendre des vacances, avoir
une vie, toussa...donc il peut être intéressant qu'une ou plusieurs
personnes agissant en backup reçoivent aussi les notifications.
Une des solutions possibles indépendamment des possibilités de
fail2ban lui-même serait de mettre en place une liste de diffusion et
d'en enregistrer l'adresse.

cordialement

Eric

Re: fail2ban - destemail et adresses multiples

2016-05-14 Par sujet Ph. Gras


Le 14 mai 2016 à 21:25, Jean-Marc  a écrit :

> Sat, 14 May 2016 15:14:13 +0200
> merkeda...@vmail.me écrivait :
> 
>> *
>> il manque un tag rtfm sur la liste ; avant toute demande, il est quant 
>> même souhaîtable de faire des recherches au préalable !
> 
> Aucun des liens ci-dessous ne donne une réponse à ma question.
> Aucun ne donne un exemple avec "destemail" et plusieurs adresses.
> 

Je pense que ce n'est pas documenté, parce que ce n'est pas prévu
pour ça, on imagine mal un admin envoyer les résultats à son voisin.

As-tu essayé des trucs comme ça ?

destemail = ad...@example.com, ad...@test.com
destemail = ad...@example.com ad...@test.com

Avec un peu de chance ça peut marcher, mais fallait le faire vendredi 13 ;-)

Bon courage,

Ph. Gras

Re: Re : fail2ban - destemail et adresses multiples

2016-05-14 Par sujet Jean-Marc

Sat, 14 May 2016 15:14:13 +0200
merkeda...@vmail.me écrivait :

> *
> il manque un tag rtfm sur la liste ; avant toute demande, il est quant 
> même souhaîtable de faire des recherches au préalable !

Aucun des liens ci-dessous ne donne une réponse à ma question.
Aucun ne donne un exemple avec "destemail" et plusieurs adresses.

Et attention à l'orthographe (pas d'accent circonflexe à "souhaitable" et 
"quand" dans ce genre d'usage s'écrit avec un "d", pas un "t").

> 
> En attente d'une suite favorable ?

C'est une plaisanterie ?

> 
> **
> 
> https://help.ubuntu.com/community/Fail2ban
> 
> https://ubuntuforums.org/showthread.php?t=1698581
>   fail2ban doesn't send emails
> 
> https://www.maketecheasier.com/protect-ssh-server-with-fail2ban-ubuntu/
> 
> https://fedoraproject.org/wiki/Fail2ban_with_FirewallD
> 
> www.pontikis.net/blog/fail2ban-install-config-debian-wheezy
> Install and Config Fail2Ban in Debian 7 Wheezy - pontikis.net
> 
> www.linux-magazine.com › Intrusion Detec...
> Intrusion Detection with fail2ban » Linux Magazine
> 
> > spécifier plusieurs adresses mails derrière
> le paramètre destemail de fail2ban ?
> 
> on fait comme Aurore , de l'espace ...
> 


Jean-Marc 


pgpKnYmUoW2Cu.pgp
Description: PGP signature

Re : fail2ban - destemail et adresses multiples

2016-05-14 Par sujet merkedanke


*
il manque un tag rtfm sur la liste ; avant toute demande, il est quant 
même souhaîtable de faire des recherches au préalable !


En attente d'une suite favorable ?

**

https://help.ubuntu.com/community/Fail2ban

https://ubuntuforums.org/showthread.php?t=1698581
 fail2ban doesn't send emails

https://www.maketecheasier.com/protect-ssh-server-with-fail2ban-ubuntu/

https://fedoraproject.org/wiki/Fail2ban_with_FirewallD

www.pontikis.net/blog/fail2ban-install-config-debian-wheezy
Install and Config Fail2Ban in Debian 7 Wheezy - pontikis.net

www.linux-magazine.com › Intrusion Detec...
Intrusion Detection with fail2ban » Linux Magazine


spécifier plusieurs adresses mails derrière

le paramètre destemail de fail2ban ?

on fait comme Aurore , de l'espace ...

Re: Fail2ban

2015-12-01 Par sujet Philippe Gras


Le 1 déc. 2015 à 17:40, Jean-Jacques Doti  a écrit :

> Le 01/12/2015 14:17, andre_deb...@numericable.fr a écrit :
>> Bonjour,
>> 
>> J'avais lancé un help sur ce sujet et modifié
>> jail.conf et fail.local
>> 
>> Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
>> (tentatives de connexions sur des comptes mail) :
>> 
>> "authentication failure; logname= uid=0 euid=0 tty=dovecot
>> ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"
>> 
>> Une personne qui n'est pas le propriétaire du mail,
>> tente de se connecter 66 fois alors que le "maxretry=3"
>> 
>> Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
>> (je l'avais bien relancé).
>> 
>> André
>> 
> Salut,
> 
> En fait, le soucis se situe directement dans la façon dont fail2ban 
> fonctionne.
> Le principe est que fail2ban scrute des fichiers de logs à la recherche de 
> certaines chaînes de caractères. Pour dovecot, c'est le fichier 
> /var/log/mail.log qui est examiné (cf /etc/fail2ban/jail.conf section 
> [dovecot]). La chaîne "authentication failure" est normalement bien repérée 
> et l'adresse IP du client récupérée (cf /etc/fail2ban/filter.d/dovecot.conf). 
> Cette adresse IP es bloquée (via iptables) si elle apparaît plus d'un 
> certains nombre de fois pendant un certain laps de temps (par défaut 3 
> apparitions en 600 secondes).
> Or dovecot a tendance à indiquer les erreurs de connexions ainsi :
> authentication failure; logname= uid=0 euid=0 tty=dovecot 
> ruser=pascal.b@ rhost=212.83.40.56 : 66 Times
> c'est à dire avec une seule ligne indiquant de nombreux échecs 
> d'authentification (il s'agit peut-être du nombre d'echec au cours d'une même 
> connexion TCP). Du coup, fail2ban n'enregistre, dans ce cas, qu'une seule 
> tentative (une seule ligne) et l'IP du client n'est pas immédiatement bloquée.
> 
> Je ne vois pas trop comment changer ce comportement facilement.
> Il doit être possible d'arriver à quelque chose d'accpetable en indiquant 
> "auth_verbose=yes" dans /etc/dovecot/conf.d/10-logging.conf et en modifiant 
> ou en ajoutant un filtre fai2ban spécifique (les tentatives 
> d'authentification sont alors toutes loggées, mais le format est différent de 
> ce que fail2ban recherche en standard avec la configuration Debian).
> 
> J'espère que je n'ai pas été trop confus dans mes explications et je suis 
> désolé de ne pas pouvoir fournir une solution clé en main…
> 
> A+
> Jean-Jacques
> 
Ah, ouais :-( C'est pas glop comme fonctionnement !

Dans ce cas, on peut mettre le 'maxretry' à 0, comme

ça l'IP est bannie après une première série de fails.

Re: Fail2ban

2015-12-01 Par sujet Philippe Gras


Le 1 déc. 2015 à 17:53, Jean-Jacques Doti  a écrit :

> Le 01/12/2015 17:50, Philippe Gras a écrit :
>> Le 1 déc. 2015 à 17:40, Jean-Jacques Doti  a écrit :
>> 
>>> Le 01/12/2015 14:17, andre_deb...@numericable.fr a écrit :
 Bonjour,
 
 J'avais lancé un help sur ce sujet et modifié
 jail.conf et fail.local
 
 Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
 (tentatives de connexions sur des comptes mail) :
 
 "authentication failure; logname= uid=0 euid=0 tty=dovecot
 ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"
 
 Une personne qui n'est pas le propriétaire du mail,
 tente de se connecter 66 fois alors que le "maxretry=3"
 
 Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
 (je l'avais bien relancé).
 
 André
 
>>> Salut,
>>> 
>>> En fait, le soucis se situe directement dans la façon dont fail2ban 
>>> fonctionne.
>>> Le principe est que fail2ban scrute des fichiers de logs à la recherche de 
>>> certaines chaînes de caractères. Pour dovecot, c'est le fichier 
>>> /var/log/mail.log qui est examiné (cf /etc/fail2ban/jail.conf section 
>>> [dovecot]). La chaîne "authentication failure" est normalement bien repérée 
>>> et l'adresse IP du client récupérée (cf 
>>> /etc/fail2ban/filter.d/dovecot.conf). Cette adresse IP es bloquée (via 
>>> iptables) si elle apparaît plus d'un certains nombre de fois pendant un 
>>> certain laps de temps (par défaut 3 apparitions en 600 secondes).
>>> Or dovecot a tendance à indiquer les erreurs de connexions ainsi :
>>> authentication failure; logname= uid=0 euid=0 tty=dovecot 
>>> ruser=pascal.b@ rhost=212.83.40.56 : 66 Times
>>> c'est à dire avec une seule ligne indiquant de nombreux échecs 
>>> d'authentification (il s'agit peut-être du nombre d'echec au cours d'une 
>>> même connexion TCP). Du coup, fail2ban n'enregistre, dans ce cas, qu'une 
>>> seule tentative (une seule ligne) et l'IP du client n'est pas immédiatement 
>>> bloquée.
>>> 
>>> Je ne vois pas trop comment changer ce comportement facilement.
>>> Il doit être possible d'arriver à quelque chose d'accpetable en indiquant 
>>> "auth_verbose=yes" dans /etc/dovecot/conf.d/10-logging.conf et en modifiant 
>>> ou en ajoutant un filtre fai2ban spécifique (les tentatives 
>>> d'authentification sont alors toutes loggées, mais le format est différent 
>>> de ce que fail2ban recherche en standard avec la configuration Debian).
>>> 
>>> J'espère que je n'ai pas été trop confus dans mes explications et je suis 
>>> désolé de ne pas pouvoir fournir une solution clé en main…
>>> 
>>> A+
>>> Jean-Jacques
>>> 
>> Ah, ouais :-( C'est pas glop comme fonctionnement !
>> 
>> Dans ce cas, on peut mettre le 'maxretry' à 0, comme
>> 
>> ça l'IP est bannie après une première série de fails.
>> 
> Oui mais non !
> Tu ne veux pas forcément bannir l'utilisateur qui paramètre sa connexion (sur 
> une nouvelle machine ou un nouveau smartphone) et qui fait une faute de 
> frappe lors de la saisie du mot de passe…
> 
> 
Sans doute, mais tu ne paramètres pas ta connexion tous les jours sur un 
nouveau bidule…

Le cas échéant, il vaut mieux penser à modifier sa règle 5 min. Pas pratique 
j'en conviens ;-)

mais une mauvaise solution est parfois meilleure que pas de solution du tout !

Re: Fail2ban

2015-12-01 Par sujet Jean-Jacques Doti


Le 01/12/2015 17:50, Philippe Gras a écrit :

Le 1 déc. 2015 à 17:40, Jean-Jacques Doti  a écrit :


Le 01/12/2015 14:17, andre_deb...@numericable.fr a écrit :

Bonjour,

J'avais lancé un help sur ce sujet et modifié
jail.conf et fail.local

Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
(tentatives de connexions sur des comptes mail) :

"authentication failure; logname= uid=0 euid=0 tty=dovecot
ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"

Une personne qui n'est pas le propriétaire du mail,
tente de se connecter 66 fois alors que le "maxretry=3"

Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
(je l'avais bien relancé).

André


Salut,

En fait, le soucis se situe directement dans la façon dont fail2ban fonctionne.
Le principe est que fail2ban scrute des fichiers de logs à la recherche de certaines 
chaînes de caractères. Pour dovecot, c'est le fichier /var/log/mail.log qui est examiné 
(cf /etc/fail2ban/jail.conf section [dovecot]). La chaîne "authentication 
failure" est normalement bien repérée et l'adresse IP du client récupérée (cf 
/etc/fail2ban/filter.d/dovecot.conf). Cette adresse IP es bloquée (via iptables) si elle 
apparaît plus d'un certains nombre de fois pendant un certain laps de temps (par défaut 3 
apparitions en 600 secondes).
Or dovecot a tendance à indiquer les erreurs de connexions ainsi :
authentication failure; logname= uid=0 euid=0 tty=dovecot 
ruser=pascal.b@ rhost=212.83.40.56 : 66 Times
c'est à dire avec une seule ligne indiquant de nombreux échecs 
d'authentification (il s'agit peut-être du nombre d'echec au cours d'une même 
connexion TCP). Du coup, fail2ban n'enregistre, dans ce cas, qu'une seule 
tentative (une seule ligne) et l'IP du client n'est pas immédiatement bloquée.

Je ne vois pas trop comment changer ce comportement facilement.
Il doit être possible d'arriver à quelque chose d'accpetable en indiquant 
"auth_verbose=yes" dans /etc/dovecot/conf.d/10-logging.conf et en modifiant ou 
en ajoutant un filtre fai2ban spécifique (les tentatives d'authentification sont alors 
toutes loggées, mais le format est différent de ce que fail2ban recherche en standard 
avec la configuration Debian).

J'espère que je n'ai pas été trop confus dans mes explications et je suis 
désolé de ne pas pouvoir fournir une solution clé en main…

A+
Jean-Jacques


Ah, ouais :-( C'est pas glop comme fonctionnement !

Dans ce cas, on peut mettre le 'maxretry' à 0, comme

ça l'IP est bannie après une première série de fails.


Oui mais non !
Tu ne veux pas forcément bannir l'utilisateur qui paramètre sa connexion 
(sur une nouvelle machine ou un nouveau smartphone) et qui fait une 
faute de frappe lors de la saisie du mot de passe…

Re: Fail2ban

2015-12-01 Par sujet Philippe Gras


Le 1 déc. 2015 à 18:57, andre_deb...@numericable.fr a écrit :

>> et  en modifiant ou en ajoutant un filtre fail2ban spécifique 
>> (les tentatives d'authentification sont alors toutes loggées, 
>> mais le format est  différent de ce que fail2ban recherche :
> 
>> J'espère que je n'ai pas été trop confus dans mes explications et je 
>> suis désolé de ne pas pouvoir fournir une solution clé en main…
>> A+  Jean-Jacques 
> 
> Merci, pas confus mais pas d'infos sur :
> "comment ajouter un filtre fail2ban spécifique" :-)

Ce n'est pas super compliqué, en fait. Il n'existe pas de tuto parce que
chaque nouveau filtre est spécifique à des besoins personnels.

Personnellement, j'ai procédé comme suit.

D'abord, je me suis fait envoyer les bans par mail (une option à ajouter
qui est décrite dans le haut du fichier jail.{conf | local})

J'ai été regarder mes logs litigieux et j'ai créé une regex dessus.

Puis, j'ai mv un filtre lambda.conf en avotboncoeur.conf

J'ai remplacé sa regex par la mienne et je l'ai testée :

/usr/bin/fail2ban-regex /var/log/nginx/monfichier.access.log 
/etc/fail2ban/filter.d/nginx-login.conf

J'y ai été contraint, parce que je n'ai pas trouvé de filtre sympa sur nginx
et j'ai pas mal d'exploits sur Wordpress.

> 
> La crainte est qu'un jour une intrusion découvre
> le mot de passe d'un compte mail.

C'est clair que ça vaut le coup de se creuser la cervelle pour trouver une
+/- bonne solution avec un maximum d'efficacité.

> 
> Bonne  soirée.
> 
> André
>

Re: Fail2ban

2015-12-01 Par sujet andre_debian

On Tuesday 01 December 2015 17:40:24 Jean-Jacques Doti wrote:
[cut]
> Je ne vois pas trop comment changer ce comportement facilement.
> Il doit être possible d'arriver à quelque chose d'accpetable en 
> indiquant "auth_verbose=yes" dans /etc/dovecot/conf.d/10-logging.conf  :

Fait.

> et  en modifiant ou en ajoutant un filtre fail2ban spécifique 
> (les tentatives d'authentification sont alors toutes loggées, 
> mais le format est  différent de ce que fail2ban recherche :

> J'espère que je n'ai pas été trop confus dans mes explications et je 
> suis désolé de ne pas pouvoir fournir une solution clé en main…
> A+  Jean-Jacques 

Merci, pas confus mais pas d'infos sur :
"comment ajouter un filtre fail2ban spécifique" :-)

La crainte est qu'un jour une intrusion découvre
le mot de passe d'un compte mail.

Bonne  soirée.

André

Re: Fail2ban

2015-12-01 Par sujet Philippe Gras


Le 1 déc. 2015 à 15:56, andre_deb...@numericable.fr a écrit :

> On Tuesday 01 December 2015 14:28:18 Philippe Gras wrote:
>> Le 1 déc. 2015 à 14:17, andre_deb...@numericable.fr a écrit :
>>> J'avais lancé un help sur ce sujet et modifié
>>> jail.conf et fail.local
>>> Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
>>> (tentatives de connexions sur des comptes mail) :
>>> "authentication failure; logname= uid=0 euid=0 tty=dovecot 
>>> ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"
>>> Une personne qui n'est pas le propriétaire du mail,
>>> tente de se connecter 66 fois alors que le "maxretry=3"
>>> Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
>>> (je l'avais bien relancé).
> 
>> Cette adresse IP est-elle rapportée dans Logwatch d'un jour à l'autre ? :
> 
> Les IP intrusives changent d'un jour à l'autre.

Bon, ben alors c'est normal. Quand tu auras banni toutes les IP du pirate ça
va se tasser, mais ça prend évidemment plusieurs jours

> 
>> La période de ban peut être augmentée (> 1 mois c'est bien) :
> 
> Quelle est la ligne à ajouter/ configurer dans les fichiers jail.conf 
> et .local ?

bantime = nombre de secondes en nombre entier
> 
>> Sinon, les requêtes peuvent avoir été envoyées en même temps, et en
>> masse, c'est une technique utilisée pour passer les filtres fail2ban :
> 
> Comment contourner la technique des ? :
> "requêtes envoyées en même temps et en masse".

À ma connaissance ce n'est pas possible. Par contre tu peux filtrer le nombre
de connections simultanées sur ton serveur ou avec iptables.
> 
> André
> 
>

Re: Fail2ban

2015-12-01 Par sujet andre_debian

On Tuesday 01 December 2015 14:28:18 Philippe Gras wrote:
> Le 1 déc. 2015 à 14:17, andre_deb...@numericable.fr a écrit :
> > J'avais lancé un help sur ce sujet et modifié
> > jail.conf et fail.local
> > Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
> > (tentatives de connexions sur des comptes mail) :
> > "authentication failure; logname= uid=0 euid=0 tty=dovecot 
> > ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"
> > Une personne qui n'est pas le propriétaire du mail,
> > tente de se connecter 66 fois alors que le "maxretry=3"
> > Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
> > (je l'avais bien relancé).

> Cette adresse IP est-elle rapportée dans Logwatch d'un jour à l'autre ? :

Les IP intrusives changent d'un jour à l'autre.

> La période de ban peut être augmentée (> 1 mois c'est bien) :

Quelle est la ligne à ajouter/ configurer dans les fichiers jail.conf 
et .local ?

> Sinon, les requêtes peuvent avoir été envoyées en même temps, et en
> masse, c'est une technique utilisée pour passer les filtres fail2ban :

Comment contourner la technique des ? :
"requêtes envoyées en même temps et en masse".

André

Re: Fail2ban

2015-12-01 Par sujet andre_debian

Bonjour,
 
J'avais lancé un help sur ce sujet et modifié jail.conf et jail.local
 
Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
(tentatives de connexions sur des comptes mail) :
 
"authentication failure; logname= uid=0 euid=0 tty=dovecot 
ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"
 
Une personne qui n'est pas le propriétaire du mail,
tente de se connecter 66 fois alors que le "maxretry=3"
 
Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
(je l'avais bien relancé).
 
André

Re: Fail2ban

2015-12-01 Par sujet Philippe Gras


Le 1 déc. 2015 à 14:17, andre_deb...@numericable.fr a écrit :

> Bonjour,
> 
> J'avais lancé un help sur ce sujet et modifié
> jail.conf et fail.local
> 
> Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
> (tentatives de connexions sur des comptes mail) :
> 
> "authentication failure; logname= uid=0 euid=0 tty=dovecot 
> ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"

Cette adresse IP est-elle rapportée dans Logwatch d'un jour à l'autre ?

La période de ban peut être augmentée (> 1 mois c'est bien ;-))

Sinon, les requêtes peuvent avoir été envoyées en même temps, et en

masse, c'est une technique utilisée pour passer les filtres fail2ban.
> 
> Une personne qui n'est pas le propriétaire du mail,
> tente de se connecter 66 fois alors que le "maxretry=3"
> 
> Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
> (je l'avais bien relancé).
> 
> André
>

Re: Fail2ban

2015-12-01 Par sujet Bernard Schoenacker

Le Tue, 1 Dec 2015 14:17:43 +0100,
andre_deb...@numericable.fr a écrit :

> Bonjour,
> 
> J'avais lancé un help sur ce sujet et modifié
> jail.conf et fail.local
> 
> Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
> (tentatives de connexions sur des comptes mail) :
> 
> "authentication failure; logname= uid=0 euid=0 tty=dovecot 
> ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"
> 
> Une personne qui n'est pas le propriétaire du mail,
> tente de se connecter 66 fois alors que le "maxretry=3"
> 
> Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
> (je l'avais bien relancé).
> 
> André
> 

bonjour,


serait il possible de comparer avec cet exemple :

http://wiki.dovecot.org/HowTo/Fail2Ban

ensuite, serait il possible de donner la version de dovecot installée ?


et de lire ceci : /usr/share/doc/fail2ban/run-rootless.txt



slt
bernard

Re: Fail2ban

2015-12-01 Par sujet Bernard Schoenacker

Le Tue, 1 Dec 2015 14:43:12 +0100,
Bernard Schoenacker  a écrit :

> Le Tue, 1 Dec 2015 14:17:43 +0100,
> andre_deb...@numericable.fr a écrit :
> 
> > Bonjour,
> > 
> > J'avais lancé un help sur ce sujet et modifié
> > jail.conf et fail.local
> > 
> > Malgré, j'ai toujours ce type de message dans mon logwatch
> > quotidien, (tentatives de connexions sur des comptes mail) :
> > 
> > "authentication failure; logname= uid=0 euid=0 tty=dovecot 
> > ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"
> > 
> > Une personne qui n'est pas le propriétaire du mail,
> > tente de se connecter 66 fois alors que le "maxretry=3"
> > 
> > Ici, fail2ban ne joue pas son rôle, il reste insensible à ses
> > configs. (je l'avais bien relancé).
> > 
> > André
> >   
> 
> bonjour,
> 
> 
> serait il possible de comparer avec cet exemple :
> 
> http://wiki.dovecot.org/HowTo/Fail2Ban
> 
> ensuite, serait il possible de donner la version de dovecot
> installée ?
> 
> 
> et de lire ceci : /usr/share/doc/fail2ban/run-rootless.txt
> 
> 
> 
> slt
> bernard
> 

bonjour,

j'ai oublié un lien :

http://www.fail2ban.org/wiki/index.php/Talk:Dovecot

slt
bernard

Re: Fail2ban

2015-12-01 Par sujet Jean-Jacques Doti


Le 01/12/2015 14:17, andre_deb...@numericable.fr a écrit :

Bonjour,

J'avais lancé un help sur ce sujet et modifié
jail.conf et fail.local

Malgré, j'ai toujours ce type de message dans mon logwatch quotidien,
(tentatives de connexions sur des comptes mail) :

"authentication failure; logname= uid=0 euid=0 tty=dovecot
ruser=pascal.b@ rhost=212.83.40.56 : 66 Times"

Une personne qui n'est pas le propriétaire du mail,
tente de se connecter 66 fois alors que le "maxretry=3"

Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs.
(je l'avais bien relancé).

André


Salut,

En fait, le soucis se situe directement dans la façon dont fail2ban 
fonctionne.
Le principe est que fail2ban scrute des fichiers de logs à la recherche 
de certaines chaînes de caractères. Pour dovecot, c'est le fichier 
/var/log/mail.log qui est examiné (cf /etc/fail2ban/jail.conf section 
[dovecot]). La chaîne "authentication failure" est normalement bien 
repérée et l'adresse IP du client récupérée (cf 
/etc/fail2ban/filter.d/dovecot.conf). Cette adresse IP es bloquée (via 
iptables) si elle apparaît plus d'un certains nombre de fois pendant un 
certain laps de temps (par défaut 3 apparitions en 600 secondes).

Or dovecot a tendance à indiquer les erreurs de connexions ainsi :
authentication failure; logname= uid=0 euid=0 tty=dovecot 
ruser=pascal.b@ rhost=212.83.40.56 : 66 Times
c'est à dire avec une seule ligne indiquant de nombreux échecs 
d'authentification (il s'agit peut-être du nombre d'echec au cours d'une 
même connexion TCP). Du coup, fail2ban n'enregistre, dans ce cas, qu'une 
seule tentative (une seule ligne) et l'IP du client n'est pas 
immédiatement bloquée.


Je ne vois pas trop comment changer ce comportement facilement.
Il doit être possible d'arriver à quelque chose d'accpetable en 
indiquant "auth_verbose=yes" dans /etc/dovecot/conf.d/10-logging.conf et 
en modifiant ou en ajoutant un filtre fai2ban spécifique (les tentatives 
d'authentification sont alors toutes loggées, mais le format est 
différent de ce que fail2ban recherche en standard avec la configuration 
Debian).


J'espère que je n'ai pas été trop confus dans mes explications et je 
suis désolé de ne pas pouvoir fournir une solution clé en main…


A+
Jean-Jacques

Re: [fail2ban][Argh!] bidouiller les fichiers système

2015-02-11 Par sujet Sébastien NOBILI

Bonjour,

Le mardi 10 février 2015 à 23:45, Philippe Gras a écrit :
 Ma question, au fait ? Je redoute de modifier des trucs à l'arrache dans les
 fichiers système, alors je préfère demander…

Elle n'est pas très claire ta question…

Je suppose que tu veux savoir si c'est propre de modifier directement les
fichiers d'un paquet (par exemple sous « /usr »).

Non, ce n'est pas propre.

Maintenant, est-ce que c'est grave ?

Pas forcément.

Si ta modification n'entraîne pas de faille au niveau de la sécurité, alors ce
n'est pas dramatique de le faire.

Par contre, quand le paquet sera mis à jour, tu perdras ta modification (et il y
a de grandes chances que tu l'aies oubliée d'ici-là et que tu te trouves donc
avec un paquet qui ne fonctionne pas comme tu le voudrais sans bien comprendre
pourquoi).

Quelle solution plus propre ?

Télécharger le paquet source, patcher le code et regénérer le paquet avec tes
modifications.

Ça résout le problème de modification directe dans « /usr », mais pas le
problème de la mise-à-jour qui viendrait écraser tes modifications.

Pour résoudre le problème de la mise-à-jour, « apt-src » est une bonne réponse.

Seb

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150211092248.ga13...@sebian.nob900.homeip.net

Re: [fail2ban][Argh!] bidouiller les fichiers système

2015-02-11 Par sujet Sébastien NOBILI


Merci de ne pas me répondre directement, je suis abonné à la liste.

Le mercredi 11 février 2015 à 11:30, judith a écrit :
 Je vais parler tout les distrib que j'utilise.  mais dans le principe,
 ça reste identique. Pour installer Foremost, vous devez activer les
 dépôts Universe et entrer la ligne de commande suivante (ou passer par
 Synaptic) :

Universe ??? C'est de l'Ubuntu ça… Ici c'est Debian et chez Debian, « foremost »
est dans main, donc rien à faire d'autre que :

 apt-get install foremost

Seb

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150211104408.gc13...@sebian.nob900.homeip.net

Re: [fail2ban][Argh!] bidouiller les fichiers système

2015-02-11 Par sujet Philippe Gras



Le 11 févr. 15 à 11:44, Sébastien NOBILI a écrit :



Merci de ne pas me répondre directement, je suis abonné à la liste.

Le mercredi 11 février 2015 à 11:30, judith a écrit :
Je vais parler tout les distrib que j'utilise.  mais dans le  
principe,

ça reste identique. Pour installer Foremost, vous devez activer les
dépôts Universe et entrer la ligne de commande suivante (ou passer  
par

Synaptic) :


Universe ??? C'est de l'Ubuntu ça… Ici c'est Debian et chez Debian,  
« foremost »

est dans main, donc rien à faire d'autre que :


apt-get install foremost


J'avais fait apt-get install fail2ban. J'ai eu tort ?



Seb

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet  
unsubscribe

vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/ 
20150211104408.gc13...@sebian.nob900.homeip.net




--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/b7baa858-de73-4d02-b189-c1d2a7831...@worldonline.fr

Re: [fail2ban][Argh!] bidouiller les fichiers système

2015-02-11 Par sujet Philippe Gras



Le 11 févr. 15 à 12:05, Sébastien NOBILI a écrit :


Le mercredi 11 février 2015 à 11:53, Philippe Gras a écrit :

Le mercredi 11 février 2015 à 11:30, judith a écrit :
Je vais parler tout les distrib que j'utilise.  mais dans le  
principe,

ça reste identique. Pour installer Foremost, vous devez activer les
dépôts Universe et entrer la ligne de commande suivante (ou  
passer par

Synaptic) :


Universe ??? C'est de l'Ubuntu ça… Ici c'est Debian et chez  
Debian, «

foremost »
est dans main, donc rien à faire d'autre que :


apt-get install foremost


J'avais fait apt-get install fail2ban. J'ai eu tort ?


Non, pas du tout.

La discussion a dérivé sur les outils de récupération de données  
supprimées /

écrasées (« foremost » en l'occurrence).


Ah, OK ! Comme je n'avais pas reçu le message, je n'avais pas compris  
de quoi

il retournait exactement…


Est-ce que ma première réponse correspondait à ta question ?

Oui, semble-t-il. J'ai commencé à regarder, ça n'a pas l'air super  
facile. Je fais 2
upgrades environ par an, et pour 15 lignes de code en trop dans mes  
logs, cela
pose une question subsidiaire : est-ce que ça vaut le coup de  
s'emmerdifier ?


Sinon, j'avais pensé qu'on aurait pu m'indiquer le chemin pour poster  
un ticket 2
réclamations quelque part, chez Debian ou Ubuntu, car l'affaire  
demeure encore

obscure en ce qui concerne ce que j'ai réellement installé :-(


Seb

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet  
unsubscribe

vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/ 
2015020500.gd13...@sebian.nob900.homeip.net




--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/72c6d69d-034e-444d-8741-b664e6fc3...@worldonline.fr

Re: [fail2ban][Argh!] bidouiller les fichiers système

2015-02-11 Par sujet judith

Le mercredi 11 février 2015 à 10:22 +0100, Sébastien NOBILI a écrit :
 Bonjour,
 
 Le mardi 10 février 2015 à 23:45, Philippe Gras a écrit :
  Ma question, au fait ? Je redoute de modifier des trucs à l'arrache dans les
  fichiers système, alors je préfère demander…
 
 Elle n'est pas très claire ta question…
 
 Je suppose que tu veux savoir si c'est propre de modifier directement les
 fichiers d'un paquet (par exemple sous « /usr »).
 
 Non, ce n'est pas propre.
 
 Maintenant, est-ce que c'est grave ?
 
 Pas forcément.
 
 Si ta modification n'entraîne pas de faille au niveau de la sécurité, alors ce
 n'est pas dramatique de le faire.
 
 Par contre, quand le paquet sera mis à jour, tu perdras ta modification (et 
 il y
 a de grandes chances que tu l'aies oubliée d'ici-là et que tu te trouves donc
 avec un paquet qui ne fonctionne pas comme tu le voudrais sans bien comprendre
 pourquoi).
 
 Quelle solution plus propre ?
 
 Télécharger le paquet source, patcher le code et regénérer le paquet avec tes
 modifications.
 
 Ça résout le problème de modification directe dans « /usr », mais pas le
 problème de la mise-à-jour qui viendrait écraser tes modifications.
 
 Pour résoudre le problème de la mise-à-jour, « apt-src » est une bonne 
 réponse.
 
 Seb
 
h, n'ayez plus peur car il est aussi possible de récupérer
simplement ce fichiers grâce à un outil en ligne de commande qui
s'appelle Foremost et qui a été développé à l'origine pour le service
d'enquête spéciales de l'US Air Force... (Allez, tous en choeur :
Waoh)

La récupération d'un fichier effacé part d'un concept simple... quand
vous supprimez un fichier, c'est uniquement le pointeur vers celui-ci
qui est cassé mais il n'est pas immédiatement re-écrabouillé par
d'autres données. Le fichier est donc toujours physiquement présent sur
le disque dur. Evidement, plus vous attendez avant de récupérer un
fichier, plus celui-ci à de chance de disparaitre à jamais...

Je vais parler tout les distrib que j'utilise.  mais dans le principe,
ça reste identique. Pour installer Foremost, vous devez activer les
dépôts Universe et entrer la ligne de commande suivante (ou passer par
Synaptic) :

apt-get install foremost

Vous devez ensuite connaitre la partition sur laquelle vous voulez
récupérer des fichiers (par exemple /dev/sda1)

Si vous voulez connaitre les fichiers qu'il est possible de récupérer
sur votre partition, entre la ligne de commande :

sudo foremost -w -i /dev/sda1 -o /recovery/foremost

Par exemple, pour récupérer des images jpg supprimées, il faut taper :

sudo foremost -t jpeg -i /dev/sda1

Foremost va alors créer un répertoire nommé output dans lequel il
placera tous les fichiers récupérés. Evidement, si les images auront
commencé à être écrasées, vous récupérerez des demi images mais c'est
déjà ça...

Il existe évidement pleins d'autres options de récupération mais les
ennoncer ici serait trop long  mais je vous recommande de lire le man
page de Foremost ici.

Source


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/1423650639.14085.5.camel@localhost

Re: [fail2ban][Argh!] bidouiller les fichiers système

2015-02-11 Par sujet Sébastien NOBILI

Le mercredi 11 février 2015 à 11:53, Philippe Gras a écrit :
 Le mercredi 11 février 2015 à 11:30, judith a écrit :
 Je vais parler tout les distrib que j'utilise.  mais dans le principe,
 ça reste identique. Pour installer Foremost, vous devez activer les
 dépôts Universe et entrer la ligne de commande suivante (ou passer par
 Synaptic) :
 
 Universe ??? C'est de l'Ubuntu ça… Ici c'est Debian et chez Debian, «
 foremost »
 est dans main, donc rien à faire d'autre que :
 
 apt-get install foremost
 
 J'avais fait apt-get install fail2ban. J'ai eu tort ?

Non, pas du tout.

La discussion a dérivé sur les outils de récupération de données supprimées /
écrasées (« foremost » en l'occurrence).

Est-ce que ma première réponse correspondait à ta question ?

Seb

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/2015020500.gd13...@sebian.nob900.homeip.net

Re: [fail2ban][Argh!] bidouiller les fichiers système

2015-02-11 Par sujet Philippe Gras



Le 11 févr. 15 à 13:00, Sébastien NOBILI a écrit :


Le mercredi 11 février 2015 à 12:37, Philippe Gras a écrit :
Ah, OK ! Comme je n'avais pas reçu le message, je n'avais pas  
compris de

quoi
il retournait exactement…


Pourtant le message avait été envoyé également à la liste. Il est  
peut-être en
attente de distribution (les messages envoyés par des non-inscrits  
sont plus

longs à arriver je crois).


Arf ! Je crois que l'Orange est encore passé au rouge pendant 1 heure  
ou 2…


Je vais encore me prendre une remontée de bretelles par le bot de la  
liste :-(



Est-ce que ma première réponse correspondait à ta question ?

Oui, semble-t-il. J'ai commencé à regarder, ça n'a pas l'air super  
facile.

Je fais 2
upgrades environ par an, et pour 15 lignes de code en trop dans  
mes logs,

cela
pose une question subsidiaire : est-ce que ça vaut le coup de  
s'emmerdifier

?


C'est souvent comme ça que ça finit :-)

La mise en place d'apt-src et la recompilation d'un paquet source  
Debian n'est

pas si compliquée que ça.

La qualité de Debian se trouve également dans son système  
d'empaquetage et les

outils qui gravitent autour, c'est _très_ bien fait !

Sinon, j'avais pensé qu'on aurait pu m'indiquer le chemin pour  
poster un

ticket 2
réclamations quelque part, chez Debian ou Ubuntu, car l'affaire  
demeure

encore
obscure en ce qui concerne ce que j'ai réellement installé :-(


Je ne connais pas fail2ban, ni la modification qui t'intéresse,  
mais si aucun
bug n'est référencé chez Debian, ça pourrait valoir le coup d'en  
ouvrir un en

donnant le lien vers la modification dans le projet amont.

Seb

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet  
unsubscribe

vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/ 
20150211120014.ge13...@sebian.nob900.homeip.net

Re: fail2ban

2015-01-17 Par sujet BERTRAND Joël


Philippe Gras wrote:


Les règles sont réenregistrées autant de fois qu'il y a de
RETURN.  Et ça enfle. J'ai relancé fail2ban hier soir, ce matin, j'ai
déjà quatre RETURN par règle. Ce soir, j'en aurais certainement une
bonne quarantaine... L'augmentation se fait bien un par un.


La logique tient peut-être au fait que f2b doit écrire une nouvelle
règle pour chaque IP bannie.

Ce qui donne à chaque fois une nouvelle ligne dans iptables, et un
RETURN supplémentaire.


	Il me semble avoir trouvé le fautif. C'est la cible 'recidive' qui est 
responsable de cela parce qu'il y a une erreur dans le code (que je n'ai 
pas réussi à corriger). Elle fait planter fail2ban qui se recharge dans 
un état bâtard, sans effacer au préalable les cibles et règles 
préexistantes.


Cordialement,

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54ba21a7.4060...@systella.fr

Re: fail2ban

2015-01-17 Par sujet Philippe Gras



Le 17 janv. 15 à 09:47, BERTRAND Joël a écrit :


Philippe Gras wrote:


Les règles sont réenregistrées autant de fois qu'il y a de
RETURN.  Et ça enfle. J'ai relancé fail2ban hier soir, ce matin,  
j'ai

déjà quatre RETURN par règle. Ce soir, j'en aurais certainement une
bonne quarantaine... L'augmentation se fait bien un par un.


La logique tient peut-être au fait que f2b doit écrire une nouvelle
règle pour chaque IP bannie.

Ce qui donne à chaque fois une nouvelle ligne dans iptables, et un
RETURN supplémentaire.


	Il me semble avoir trouvé le fautif. C'est la cible 'recidive' qui  
est responsable de cela parce qu'il y a une erreur dans le code  
(que je n'ai pas réussi à corriger). Elle fait planter fail2ban qui  
se recharge dans un état bâtard, sans effacer au préalable les  
cibles et règles préexistantes.


J'ai plein d'erreurs aussi dans mes logs de fail2ban, mais sur  
d'autres filtres.


Il faudra que je me penche là-dessus sérieusement, car le paramétrage me

semble beaucoup plus fin que sur tous les tutos que j'ai consultés…



Cordialement,

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet  
unsubscribe

vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54ba21a7.4060...@systella.fr



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1b73c166-a5e5-4bf2-a1ce-2681342ab...@worldonline.fr

Re: fail2ban

2015-01-16 Par sujet Philippe Gras



	Les règles sont réenregistrées autant de fois qu'il y a de  
RETURN.  Et ça enfle. J'ai relancé fail2ban hier soir, ce matin,  
j'ai déjà quatre RETURN par règle. Ce soir, j'en aurais  
certainement une bonne quarantaine... L'augmentation se fait bien  
un par un.


La logique tient peut-être au fait que f2b doit écrire une nouvelle  
règle pour chaque IP bannie.


Ce qui donne à chaque fois une nouvelle ligne dans iptables, et un  
RETURN supplémentaire.


Maintenant que j'y pense…


Bonne journée,

JKB

--
Dr. BERTRAND Joël
SYSTELLA S.A.R.L., 10, place de l'école, 68000 COLMAR, FRANCE
Tél.: +33 (0) 973870201, GSM: +33 (0) 616018060, Fax: +33 (0)  
149297395

http://www.systella.fr

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet  
unsubscribe

vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54b8bf51.1030...@systella.fr




--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/15eedb50-b997-40be-bea4-08b61f7c8...@worldonline.fr

Re: fail2ban

2015-01-15 Par sujet BERTRAND Joël


Philippe Gras a écrit :


J'observe un comportement étrange sans savoir si ce comportement
est provoqué par le patch IPv6 (mais il n'a rien de complexe) ou si
c'est dû à l'augmentation ces derniers jours des attaques. En effet,
j'ai un /29 et je subis actuellement en IPv4 des attaques sur toutes
les IP à un rythme soutenu.


Ça a rapport avec ça ?
http://fr.reuters.com/article/topNews/idFRKBN0KO1NZ20150115


Je ne sais pas. Je constate simplement...


Je n'ai rien vu du tout, c'est bizarre ! Moi qui chope toutes les m…
d'habitude.


Heureux homme.

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54b7f9da.40...@systella.fr

Re: fail2ban

2015-01-15 Par sujet Philippe Gras



	J'observe un comportement étrange sans savoir si ce comportement  
est provoqué par le patch IPv6 (mais il n'a rien de complexe) ou si  
c'est dû à l'augmentation ces derniers jours des attaques. En  
effet, j'ai un /29 et je subis actuellement en IPv4 des attaques  
sur toutes les IP à un rythme soutenu.


Ça a rapport avec ça ?
http://fr.reuters.com/article/topNews/idFRKBN0KO1NZ20150115

Je n'ai rien vu du tout, c'est bizarre ! Moi qui chope toutes les m…  
d'habitude.



Suis-je le seul à observer cela ?

Cordialement,

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet  
unsubscribe

vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54b6e498.4050...@systella.fr



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/c55380a9-91a8-4e4f-893f-323e3c593...@worldonline.fr

Re: fail2ban

2015-01-15 Par sujet BERTRAND Joël


BERTRAND Joël wrote:

Philippe Gras a écrit :


J'observe un comportement étrange sans savoir si ce comportement
est provoqué par le patch IPv6 (mais il n'a rien de complexe) ou si
c'est dû à l'augmentation ces derniers jours des attaques. En effet,
j'ai un /29 et je subis actuellement en IPv4 des attaques sur toutes
les IP à un rythme soutenu.


Ça a rapport avec ça ?
http://fr.reuters.com/article/topNews/idFRKBN0KO1NZ20150115


 Je ne sais pas. Je constate simplement...


Je n'ai rien vu du tout, c'est bizarre ! Moi qui chope toutes les m…
d'habitude.


 Heureux homme.


Tiens, je viens de m'apercevoir d'un autre truc amusant :

Root rayleigh:[/export/home/bertrand]  iptables -L
Chain INPUT (policy DROP)
target prot opt source   destination
f2b-ejabberd-auth  tcp  --  anywhere anywhere 
multiport dports xmpp-client
f2b-courier-auth  tcp  --  anywhere anywhere 
multiport dports smtp,urd,submission,imap3,imaps,pop3,pop3s
f2b-sendmail-reject  tcp  --  anywhere anywhere 
multiport dports smtp,urd,submission
f2b-sendmail-auth  tcp  --  anywhere anywhere 
multiport dports submission,urd,smtp
f2b-apache-auth  tcp  --  anywhere anywhere 
multiport dports http,https
f2b-sshd   tcp  --  anywhere anywhere multiport 
dports ssh
f2b-ejabberd-auth  tcp  --  anywhere anywhere 
multiport dports xmpp-client
f2b-courier-auth  tcp  --  anywhere anywhere 
multiport dports smtp,urd,submission,imap3,imaps,pop3,pop3s
f2b-sendmail-reject  tcp  --  anywhere anywhere 
multiport dports smtp,urd,submission
f2b-sendmail-auth  tcp  --  anywhere anywhere 
multiport dports submission,urd,smtp
f2b-apache-auth  tcp  --  anywhere anywhere 
multiport dports http,https
f2b-sshd   tcp  --  anywhere anywhere multiport 
dports ssh
f2b-ejabberd-auth  tcp  --  anywhere anywhere 
multiport dports xmpp-client
f2b-courier-auth  tcp  --  anywhere anywhere 
multiport dports smtp,urd,submission,imap3,imaps,pop3,pop3s
f2b-sendmail-reject  tcp  --  anywhere anywhere 
multiport dports smtp,urd,submission
f2b-sendmail-auth  tcp  --  anywhere anywhere 
multiport dports submission,urd,smtp
f2b-apache-auth  tcp  --  anywhere anywhere 
multiport dports http,https
f2b-sshd   tcp  --  anywhere anywhere multiport 
dports ssh
f2b-ejabberd-auth  tcp  --  anywhere anywhere 
multiport dports xmpp-client
f2b-courier-auth  tcp  --  anywhere anywhere 
multiport dports smtp,urd,submission,imap3,imaps,pop3,pop3s
f2b-sendmail-reject  tcp  --  anywhere anywhere 
multiport dports smtp,urd,submission
f2b-sendmail-auth  tcp  --  anywhere anywhere 
multiport dports submission,urd,smtp
f2b-apache-auth  tcp  --  anywhere anywhere 
multiport dports http,https
f2b-sshd   tcp  --  anywhere anywhere multiport 
dports ssh


	Les règles sont réenregistrées autant de fois qu'il y a de RETURN.  Et 
ça enfle. J'ai relancé fail2ban hier soir, ce matin, j'ai déjà quatre 
RETURN par règle. Ce soir, j'en aurais certainement une bonne 
quarantaine... L'augmentation se fait bien un par un.


Bonne journée,

JKB

--
Dr. BERTRAND Joël
SYSTELLA S.A.R.L., 10, place de l'école, 68000 COLMAR, FRANCE
Tél.: +33 (0) 973870201, GSM: +33 (0) 616018060, Fax: +33 (0) 149297395
http://www.systella.fr

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54b8bf51.1030...@systella.fr

Re: fail2ban

2015-01-15 Par sujet Daniel Caillibaud

Le 15/01/15 à 18:33, BERTRAND Joël joel.bertr...@systella.fr a écrit :
BJ  Ça a rapport avec ça ?
BJ  http://fr.reuters.com/article/topNews/idFRKBN0KO1NZ20150115
BJ 
BJ Je ne sais pas. Je constate simplement...
BJ 
BJ  Je n'ai rien vu du tout, c'est bizarre ! Moi qui chope toutes les m…
BJ  d'habitude.

P'tet que tu tiens à jour tes machines et applis...

La grande majorité des défacements concernent des sites sur des CMS pas à 
jour, parfois
depuis des années...

-- 
Daniel

Un peuple prêt à sacrifier un peu de liberté pour un peu de sécurité 
ne mérite ni l'une ni l'autre, et finit par perdre les deux.
Benjamin Franklin

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150116015914.3e6f2...@quad.lairdutemps.org

Re: fail2ban

2015-01-15 Par sujet Philippe Gras



Le 16 janv. 15 à 01:59, Daniel Caillibaud a écrit :

Le 15/01/15 à 18:33, BERTRAND Joël joel.bertr...@systella.fr a  
écrit :

BJ  Ça a rapport avec ça ?
BJ  http://fr.reuters.com/article/topNews/idFRKBN0KO1NZ20150115
BJ
BJ  Je ne sais pas. Je constate simplement...
BJ
BJ  Je n'ai rien vu du tout, c'est bizarre ! Moi qui chope toutes  
les m…

BJ  d'habitude.

P'tet que tu tiens à jour tes machines et applis...


Bah, non justement ! Je déteste courir derrière les mises à jour.

Le serveur est à jour de Noël, mais pas les CMS actuellement !

Je trouve que je subis beaucoup d'attaques, mais elles ont pour

le moment toutes été repoussées.

Par contre, je scrute mes logs régulièrement. J'ai rencontré pas

mal de gens qui ne se souciaient pas des attaques, parce qu'ils

les ignoraient. Beaucoup ne s'en rendent même pas compte.

Ou trop tard… De ceux-là, j'en ai vu beaucoup aussi !



La grande majorité des défacements concernent des sites sur des  
CMS pas à jour, parfois

depuis des années...

--
Daniel

Un peuple prêt à sacrifier un peu de liberté pour un peu de sécurité
ne mérite ni l'une ni l'autre, et finit par perdre les deux.
Benjamin Franklin

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet  
unsubscribe

vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/ 
20150116015914.3e6f2...@quad.lairdutemps.org




--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/631c35d6-9b35-450b-9f09-534aba085...@worldonline.fr

Re: fail2ban

2015-01-14 Par sujet Christophe


Bonsoir,

On va encore dire que ça ne répond pas au besoin de l'OP , mais :

Le 14/01/2015 22:50, BERTRAND Joël a écrit :

 Bonsoir à tous,

 J'ai un truc un peu bizarre avec fail2ban 0.9.1 que j'ai installé
sur un serveur. J'ai patché l'outil pour qu'il traite aussi les IPv6
(https://tetsumaki.net/blog/article/2014-03-04-ajout-du-support-ipv6-sur-fail2ban.html).


Je m'étais tenté à ça, il y a quelques mois/années, sans aucun succès 
(en particulier ce qui concerne IPv6) .


Depuis j'utilise sshguard  ...

@+
Christophe.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54b6edc2.5040...@stuxnet.org

Re: fail2ban

2015-01-14 Par sujet BERTRAND Joël


Philippe Gras wrote:


Le 14 janv. 15 à 23:35, BERTRAND Joël a écrit :


Philippe Gras wrote:


Le 14 janv. 15 à 23:22, BERTRAND Joël a écrit :


Philippe Gras wrote:

Je crois que le RETURN, ça veut seulement dire que la règle subit un
transfert.

De fait si j'ai bien compris, elle est passée par iptables à fail2ban
qui va prendre

la main dessus et la passer au tamis, puis la retourner à iptables
avec
les IP qu'il

faut bannir.



Ça, je sais. Ce qui m'étonne, ce n'est pas qu'il y ait un RETURN
sur chacune des nouvelles cibles ajoutées par fail2ban, mais qu'il y
ait plusieurs RETURN par cible et que ce nombre va en croissant au fil
du temps...


Tu as 3 références à chaque règle ou ça augmente ? Si ça augmente, c'est
x 3 ?


Non, j'ai plutôt l'impression que c'est un par un. Mais en dehors
de la règle 'recidive' toutes augmentent en même temps et comportent
le même nombre de RETURN.


Rien compris !  Quand j'observe tes extraits :
Chain f2b-apache-auth (3 references)
target prot opt source   destination
RETURN all  --  anywhere anywhere
RETURN all  --  anywhere anywhere
RETURN all  --  anywhere anywhere

C'est par 3, toujours par 3. Ce qui peut sembler logique vu qu'il y a 3
fichiers à patcher.

Tu pourrais jeter un coup d'œil à l'intérieur pour voir s'ils ne
retournent pas chacun une


	On s'est mal compris. En ce moment, j'ai trois lignes RETURN par cible. 
Mais lorsque je lance fail2ban, je n'ai qu'un RETURN par cible. Et ce 
soir, j'avais 49 RETURN par cible avant de relancer le service.


	J'ai regardé les fichiers en question avant d'écrire ici et je ne vois 
pas trop ce qui pourrait provoquer un tel comportement.


Cordialement,

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54b6f3aa.9070...@systella.fr

Re: fail2ban

2015-01-14 Par sujet Philippe Gras



Le 14 janv. 15 à 23:54, BERTRAND Joël a écrit :


Philippe Gras wrote:


Le 14 janv. 15 à 23:35, BERTRAND Joël a écrit :


Philippe Gras wrote:


Le 14 janv. 15 à 23:22, BERTRAND Joël a écrit :


Philippe Gras wrote:
Je crois que le RETURN, ça veut seulement dire que la règle  
subit un

transfert.

De fait si j'ai bien compris, elle est passée par iptables à  
fail2ban

qui va prendre

la main dessus et la passer au tamis, puis la retourner à  
iptables

avec
les IP qu'il

faut bannir.



Ça, je sais. Ce qui m'étonne, ce n'est pas qu'il y ait un  
RETURN
sur chacune des nouvelles cibles ajoutées par fail2ban, mais  
qu'il y
ait plusieurs RETURN par cible et que ce nombre va en croissant  
au fil

du temps...


Tu as 3 références à chaque règle ou ça augmente ? Si ça  
augmente, c'est

x 3 ?


Non, j'ai plutôt l'impression que c'est un par un. Mais en  
dehors

de la règle 'recidive' toutes augmentent en même temps et comportent
le même nombre de RETURN.


Rien compris !  Quand j'observe tes extraits :
Chain f2b-apache-auth (3 references)
target prot opt source   destination
RETURN all  --  anywhere anywhere
RETURN all  --  anywhere anywhere
RETURN all  --  anywhere anywhere

C'est par 3, toujours par 3. Ce qui peut sembler logique vu qu'il  
y a 3

fichiers à patcher.

Tu pourrais jeter un coup d'œil à l'intérieur pour voir s'ils ne
retournent pas chacun une


	On s'est mal compris. En ce moment, j'ai trois lignes RETURN par  
cible. Mais lorsque je lance fail2ban, je n'ai qu'un RETURN par  
cible. Et ce soir, j'avais 49 RETURN par cible avant de relancer le  
service.


Ça veut dire que le patch te balance 1 RETURN par IP bannie, c'est ça ?


	J'ai regardé les fichiers en question avant d'écrire ici et je ne  
vois pas trop ce qui pourrait provoquer un tel comportement.


Sinon, tu peux regarder ça :
iptables -S | grep fail2ban et cat /var/log/fail2ban.log

Je me sers beaucoup du fichier de log en ce moment pour voir comment  
f2b se comporte, car je l'ai installé récemment.


(offert à mon serveur pour Noël)



Cordialement,

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet  
unsubscribe

vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54b6f3aa.9070...@systella.fr



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/b68ee115-9b34-4337-a7a6-9344bf4ee...@worldonline.fr

Re: fail2ban

2015-01-14 Par sujet BERTRAND Joël


Philippe Gras wrote:

Je crois que le RETURN, ça veut seulement dire que la règle subit un
transfert.

De fait si j'ai bien compris, elle est passée par iptables à fail2ban
qui va prendre

la main dessus et la passer au tamis, puis la retourner à iptables avec
les IP qu'il

faut bannir.



	Ça, je sais. Ce qui m'étonne, ce n'est pas qu'il y ait un RETURN sur 
chacune des nouvelles cibles ajoutées par fail2ban, mais qu'il y ait 
plusieurs RETURN par cible et que ce nombre va en croissant au fil du 
temps...


Cordialement,

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54b6ec0d.1020...@systella.fr

Re: fail2ban

2015-01-14 Par sujet BERTRAND Joël


Philippe Gras wrote:


Le 14 janv. 15 à 23:22, BERTRAND Joël a écrit :


Philippe Gras wrote:

Je crois que le RETURN, ça veut seulement dire que la règle subit un
transfert.

De fait si j'ai bien compris, elle est passée par iptables à fail2ban
qui va prendre

la main dessus et la passer au tamis, puis la retourner à iptables avec
les IP qu'il

faut bannir.



Ça, je sais. Ce qui m'étonne, ce n'est pas qu'il y ait un RETURN
sur chacune des nouvelles cibles ajoutées par fail2ban, mais qu'il y
ait plusieurs RETURN par cible et que ce nombre va en croissant au fil
du temps...


Tu as 3 références à chaque règle ou ça augmente ? Si ça augmente, c'est
x 3 ?


	Non, j'ai plutôt l'impression que c'est un par un. Mais en dehors de la 
règle 'recidive' toutes augmentent en même temps et comportent le même 
nombre de RETURN.


Cordialement,

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54b6ef45.6090...@systella.fr

Re: fail2ban

2015-01-14 Par sujet Philippe Gras



Le 14 janv. 15 à 23:22, BERTRAND Joël a écrit :


Philippe Gras wrote:

Je crois que le RETURN, ça veut seulement dire que la règle subit un
transfert.

De fait si j'ai bien compris, elle est passée par iptables à fail2ban
qui va prendre

la main dessus et la passer au tamis, puis la retourner à iptables  
avec

les IP qu'il

faut bannir.



	Ça, je sais. Ce qui m'étonne, ce n'est pas qu'il y ait un RETURN  
sur chacune des nouvelles cibles ajoutées par fail2ban, mais qu'il  
y ait plusieurs RETURN par cible et que ce nombre va en croissant  
au fil du temps...


Tu as 3 références à chaque règle ou ça augmente ? Si ça augmente,  
c'est x 3 ?




Cordialement,

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet  
unsubscribe

vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54b6ec0d.1020...@systella.fr



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/7a063146-193c-41a0-aa68-a61edb48c...@worldonline.fr

Re: fail2ban

2015-01-14 Par sujet Philippe Gras

Je crois que le RETURN, ça veut seulement dire que la règle subit un  
transfert.


De fait si j'ai bien compris, elle est passée par iptables à fail2ban  
qui va prendre


la main dessus et la passer au tamis, puis la retourner à iptables  
avec les IP qu'il


faut bannir.

Le 14 janv. 15 à 22:50, BERTRAND Joël a écrit :


Bonsoir à tous,

	J'ai un truc un peu bizarre avec fail2ban 0.9.1 que j'ai installé  
sur un serveur. J'ai patché l'outil pour qu'il traite aussi les  
IPv6 (https://tetsumaki.net/blog/article/2014-03-04-ajout-du- 
support-ipv6-sur-fail2ban.html).


	J'observe un comportement étrange sans savoir si ce comportement  
est provoqué par le patch IPv6 (mais il n'a rien de complexe) ou si  
c'est dû à l'augmentation ces derniers jours des attaques. En  
effet, j'ai un /29 et je subis actuellement en IPv4 des attaques  
sur toutes les IP à un rythme soutenu.


ip(6)tables -L renvoient :
... (mes règles habituelles)
Chain f2b-apache-auth (3 references)
target prot opt source   destination
RETURN all  --  anywhere anywhere
RETURN all  --  anywhere anywhere
RETURN all  --  anywhere anywhere

Chain f2b-courier-auth (3 references)
target prot opt source   destination
RETURN all  --  anywhere anywhere
RETURN all  --  anywhere anywhere
RETURN all  --  anywhere anywhere

Chain f2b-ejabberd-auth (3 references)
target prot opt source   destination
RETURN all  --  anywhere anywhere
RETURN all  --  anywhere anywhere
RETURN all  --  anywhere anywhere


	Il m'arrive d'avoir une centaine de RETURN au bout d'une journée.  
Je relance fail2ban et ça fonctionne jusqu'à la prochaine fois.


Suis-je le seul à observer cela ?

Cordialement,

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet  
unsubscribe

vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54b6e498.4050...@systella.fr



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/ba95a7b8-9391-4c00-8ab7-9f6160072...@worldonline.fr

Re: fail2ban

2015-01-14 Par sujet Philippe Gras



Le 14 janv. 15 à 23:35, BERTRAND Joël a écrit :


Philippe Gras wrote:


Le 14 janv. 15 à 23:22, BERTRAND Joël a écrit :


Philippe Gras wrote:
Je crois que le RETURN, ça veut seulement dire que la règle  
subit un

transfert.

De fait si j'ai bien compris, elle est passée par iptables à  
fail2ban

qui va prendre

la main dessus et la passer au tamis, puis la retourner à  
iptables avec

les IP qu'il

faut bannir.



Ça, je sais. Ce qui m'étonne, ce n'est pas qu'il y ait un RETURN
sur chacune des nouvelles cibles ajoutées par fail2ban, mais qu'il y
ait plusieurs RETURN par cible et que ce nombre va en croissant  
au fil

du temps...


Tu as 3 références à chaque règle ou ça augmente ? Si ça augmente,  
c'est

x 3 ?


	Non, j'ai plutôt l'impression que c'est un par un. Mais en dehors  
de la règle 'recidive' toutes augmentent en même temps et  
comportent le même nombre de RETURN.



Rien compris !  Quand j'observe tes extraits :
Chain f2b-apache-auth (3 references)
target prot opt source   destination
RETURN all  --  anywhere anywhere
RETURN all  --  anywhere anywhere
RETURN all  --  anywhere anywhere

C'est par 3, toujours par 3. Ce qui peut sembler logique vu qu'il y a  
3 fichiers à patcher.


Tu pourrais jeter un coup d'œil à l'intérieur pour voir s'ils ne  
retournent pas chacun une


instruction similaire, pas vrai ?


Cordialement,

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet  
unsubscribe

vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54b6ef45.6090...@systella.fr



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/578373bf-3777-47f4-9972-3fa327ba7...@worldonline.fr

Re: Fail2ban : pas de blocage d'accès et pas de logs

2013-02-20 Par sujet gardouille


Le 19/02/2013 13:52, Médor Tégé a écrit :

Bonjour,


Salut,

La configuration que j'ai pour ma jail ssh:

[ssh]
enabled = true
port  = ssh,sftp
filter  = sshd
action = iptables-multiport[name=SSH,port=22,protocol=tcp] 
sendmail[dest=ad...@gardouille.fr,name=ssh,sender=fail2...@gardouille.fr]

# Log file
logpath  = /var/log/auth.log
# Analyze the last 600 secondes (10minutes)
findtime = 600
# bantime: 25h
bantime = 9
# Maximum failed try
maxretry = 3

Tu peux t'amuser à tester en modifiant bantime et ignoreip et en 
faisant quelques erreurs de connection sur ton poste pour voir ce que ça 
donne. Évite le bannissement pendant 1 semaine de ta propre ip ^^




Et pourtant les tentatives d'accès root par ssh ne sont pas mises
dedans, et ne sont pas bloquées par fail2ban ?
Où je dois regarder ? Merci !


Pour savoir ce qui est bloqué par fail2ban:

# fail2ban-client status ssh


Si tu as conservé le filtre fournit par défaut, toutes mauvaises 
connections (quelque soit l'user) sera prise en compte par fail2ban et 
donc ip bannie au bout des X tentatives en fonction des paramètres tu as 
spécifié.



--
--
Gardouille-kun
mail: gardoui...@gmail.com
jabber: gardoui...@im.gardouille.fr
--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/5124b2a0.8060...@gmail.com

Re: fail2ban / ssh dans Lenny: Ne fonctionne pas

2009-10-25 Par sujet S e r g e

Le Sunday 25 October 2009 10:14:36 Merwin, vous avez écrit :
 Bonjour à tous,
Salut Merwin, 

 J'ai installé fail2ban, et configuré celui-ci pour qu'il vérifie les
 logs de SSH, afin de banir l'ip au bout de 3 erreurs de connexions:

   [ssh]

   enabled = true
   port= ssh
   filter  = sshd
   logpath  = /var/log/auth.log
   maxretry = 3

 Mon 'banaction' est défini à 'shorewall', (qui existe bien dans
 action.d), et qui est bien lancé/configuré.

 Lorsque je fais:

   fail2ban-regex /var/log.auth.log /etc/fail2ban/filter.d/sshd.conf


Et avec cette syntaxe:

% fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

Ou bien en testant d'autres journaux:

% fail2ban-regex /var/log/messages /etc/fail2ban/filter.d/sshd.conf

 J'obtiens aucun résultat:

   Sorry, no match

 Je n'ai pas touché au filter.d/sshd.conf, qui contient ceci:

 failregex = ^%(__prefix_line)s(?:error: PAM: )?Authentication failure
 for .* from HOST\s*$
 ^%(__prefix_line)s(?:error: PAM: )?User not known to the
 underlying authentication module for .* from HOST\s*$
 ^%(__prefix_line)sFailed (?:password|publickey) for .* from
 HOST(?: port \d*)?(?: ssh\d*)?$
 ^%(__prefix_line)sROOT LOGIN REFUSED.* FROM HOST\s*$
 ^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from
 HOST\s*$
 ^%(__prefix_line)sUser .+ from HOST not allowed because
 not listed in AllowUsers$
 ^%(__prefix_line)sUser .+ from HOST not allowed because
 none of user's groups are listed in AllowGroups\s*$
 ^%(__prefix_line)sauthentication failure; logname=\S* uid=
 \S* euid=\S* tty=\S* ruser=\S* rhost=HOST(?:\s+user=.*)?\s*$
 ^%(__prefix_line)srefused connect from \S+ \(HOST\)\s*$
 ^%(__prefix_line)sAddress HOST .* POSSIBLE BREAK-IN
 ATTEMPT\s*$

 Et mon fichier de log contient cette ligne, qui devrait correspondre au
 3ème regex, hors ce n'est pas le cas!

 Oct 25 10:09:30 universe sshd[13959]: Failed password for merwin from
 90.10.109.43 port 35564 ssh2

 Je répète je n'ai pas touché à la regex! Merci d'avance ;-)


@+
-- 
(o_
(/)_
S e r g e

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: fail2ban / ssh dans Lenny: Ne fonctionne pas

2009-10-25 Par sujet Merwin

Le dimanche 25 octobre 2009 à 12:45 +0100, S e r g e a écrit :
 Le Sunday 25 October 2009 10:14:36 Merwin, vous avez écrit :
  Bonjour à tous,
 Salut Merwin, 
 
  J'ai installé fail2ban, et configuré celui-ci pour qu'il vérifie les
  logs de SSH, afin de banir l'ip au bout de 3 erreurs de connexions:
 
  [ssh]
 
  enabled = true
  port= ssh
  filter  = sshd
  logpath  = /var/log/auth.log
  maxretry = 3
 
  Mon 'banaction' est défini à 'shorewall', (qui existe bien dans
  action.d), et qui est bien lancé/configuré.
 
  Lorsque je fais:
 
  fail2ban-regex /var/log.auth.log /etc/fail2ban/filter.d/sshd.conf
 
 
 Et avec cette syntaxe:
 
 % fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf


Ok, donc en effet j'avais fais n'importe quoi, pusique j'avais mis '.'
au lieu d'un '/'. Donc en analysant le bon fichier:

Summary
===

Addresses found:
[1]
[2]
[3]
90.10.109.43 (Sun Oct 25 10:09:30 2009)
...

Donc il trouve bien la ligne et en sort l'adresse IP. Seulement quand je
vais voir dans les logs de fail2ban, il m'indique bien:

2009-10-25 03:02:23,735 fail2ban.filter : DEBUG  /var/log/auth.log has
been modified
2009-10-25 03:02:23,736 fail2ban.filter.datedetector: DEBUG  Sorting the
template list

Donc il détecte bien que le fichier est modifié, donc je suppose qu'il
l'analyse avec le regex ci-dessus, mais il ne banni personne...

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: fail2ban / ssh dans Lenny: Ne fonctionne pas

2009-10-25 Par sujet S e r g e

Le Sunday 25 October 2009 13:22:55 Merwin, vous avez écrit :
 Le dimanche 25 octobre 2009 à 12:45 +0100, S e r g e a écrit :
  Le Sunday 25 October 2009 10:14:36 Merwin, vous avez écrit :
   Bonjour à tous,
 
  Salut Merwin,
 
   J'ai installé fail2ban, et configuré celui-ci pour qu'il vérifie les
   logs de SSH, afin de banir l'ip au bout de 3 erreurs de connexions:
  
 [ssh]
  
 enabled = true
 port= ssh
 filter  = sshd
 logpath  = /var/log/auth.log
 maxretry = 3
  
   Mon 'banaction' est défini à 'shorewall', (qui existe bien dans
   action.d), et qui est bien lancé/configuré.
  
   Lorsque je fais:
  
 fail2ban-regex /var/log.auth.log /etc/fail2ban/filter.d/sshd.conf
 
  Et avec cette syntaxe:
 
  % fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

 Ok, donc en effet j'avais fais n'importe quoi, pusique j'avais mis '.'
 au lieu d'un '/'. Donc en analysant le bon fichier:

 Summary
 ===

 Addresses found:
 [1]
 [2]
 [3]
 90.10.109.43 (Sun Oct 25 10:09:30 2009)
 ...

 Donc il trouve bien la ligne et en sort l'adresse IP. Seulement quand je
 vais voir dans les logs de fail2ban, il m'indique bien:

 2009-10-25 03:02:23,735 fail2ban.filter : DEBUG  /var/log/auth.log has
 been modified
 2009-10-25 03:02:23,736 fail2ban.filter.datedetector: DEBUG  Sorting the
 template list

 Donc il détecte bien que le fichier est modifié, donc je suppose qu'il
 l'analyse avec le regex ci-dessus, mais il ne banni personne...

Je ne sais pas l'action que tu as choisi ...un oeil sur iptables/ip6tables :

% iptables -n -L
% ip6tables -n -L

Comme teste, demande à un ami de se connecter sur ton IP au port SSH (22).


@+
-- 
(o_
(/)_
S e r g e

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: fail2ban / ssh dans Lenny: Ne fonctionne pas

2009-10-25 Par sujet Merwin

Le dimanche 25 octobre 2009 à 13:34 +0100, S e r g e a écrit :
 Le Sunday 25 October 2009 13:22:55 Merwin, vous avez écrit :
  Le dimanche 25 octobre 2009 à 12:45 +0100, S e r g e a écrit :
   Le Sunday 25 October 2009 10:14:36 Merwin, vous avez écrit :
Bonjour à tous,
  
   Salut Merwin,
  
J'ai installé fail2ban, et configuré celui-ci pour qu'il vérifie les
logs de SSH, afin de banir l'ip au bout de 3 erreurs de connexions:
   
[ssh]
   
enabled = true
port= ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 3
   
Mon 'banaction' est défini à 'shorewall', (qui existe bien dans
action.d), et qui est bien lancé/configuré.
   
Lorsque je fais:
   
fail2ban-regex /var/log.auth.log 
/etc/fail2ban/filter.d/sshd.conf
  
   Et avec cette syntaxe:
  
   % fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf
 
  Ok, donc en effet j'avais fais n'importe quoi, pusique j'avais mis '.'
  au lieu d'un '/'. Donc en analysant le bon fichier:
 
  Summary
  ===
 
  Addresses found:
  [1]
  [2]
  [3]
  90.10.109.43 (Sun Oct 25 10:09:30 2009)
  ...
 
  Donc il trouve bien la ligne et en sort l'adresse IP. Seulement quand je
  vais voir dans les logs de fail2ban, il m'indique bien:
 
  2009-10-25 03:02:23,735 fail2ban.filter : DEBUG  /var/log/auth.log has
  been modified
  2009-10-25 03:02:23,736 fail2ban.filter.datedetector: DEBUG  Sorting the
  template list
 
  Donc il détecte bien que le fichier est modifié, donc je suppose qu'il
  l'analyse avec le regex ci-dessus, mais il ne banni personne...
 
 Je ne sais pas l'action que tu as choisi ...un oeil sur iptables/ip6tables :
 
 % iptables -n -L
 % ip6tables -n -L
 
 Comme teste, demande à un ami de se connecter sur ton IP au port SSH (22).
 
 
 @+
 -- 
 (o_
 (/)_
 S e r g e
 

Dans banaction j'ai mit 'shorewall', qui correspond à la valeur par
defaut contenu dans /etc/fail2ban/action.d/shorewall.conf.

Dedans on y trouves ces deux lignes (je zappe les commentaires etc):

actionban = shorewall drop ip
actionban = shorewall allow ip

iptables ne contient aucune entrée dans DROP/REJECT concernant une
adresse IP quelquonque. J'essaye de me connecter moi même à la machine
distante en me trompant de mot de passe, et comme dit précédemment, il
détecte que le fichier de log est modifié mais ne fais rien.

J'ai même tenté avec 'iptables-multiport' comme action, mais idem, c'est
comme s'il n'essayait même pas d'éxécuté l'action, pusique rien n'est
logé, aucune erreur rien...

Si vous voulez essayer, voici l'ip de la machine: 91.121.52.49 / 22

Cela pourrait t'il venir du fait que je sois en même temps connecté en
ssh ? Et que du coup il ne banni pas quelqu'un déjà connecté?

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: fail2ban / ssh dans Lenny: Ne fonctionne pas

2009-10-25 Par sujet S e r g e

Le Sunday 25 October 2009 13:41:49 Merwin, vous avez écrit :
 Le dimanche 25 octobre 2009 à 13:34 +0100, S e r g e a écrit :
  Le Sunday 25 October 2009 13:22:55 Merwin, vous avez écrit :
   Le dimanche 25 octobre 2009 à 12:45 +0100, S e r g e a écrit :
Le Sunday 25 October 2009 10:14:36 Merwin, vous avez écrit :
 Bonjour à tous,
   
Salut Merwin,
   
 J'ai installé fail2ban, et configuré celui-ci pour qu'il vérifie
 les logs de SSH, afin de banir l'ip au bout de 3 erreurs de
 connexions:

   [ssh]

   enabled = true
   port= ssh
   filter  = sshd
   logpath  = /var/log/auth.log
   maxretry = 3

 Mon 'banaction' est défini à 'shorewall', (qui existe bien dans
 action.d), et qui est bien lancé/configuré.

 Lorsque je fais:

   fail2ban-regex /var/log.auth.log 
 /etc/fail2ban/filter.d/sshd.conf
   
Et avec cette syntaxe:
   
% fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf
  
   Ok, donc en effet j'avais fais n'importe quoi, pusique j'avais mis '.'
   au lieu d'un '/'. Donc en analysant le bon fichier:
  
   Summary
   ===
  
   Addresses found:
   [1]
   [2]
   [3]
   90.10.109.43 (Sun Oct 25 10:09:30 2009)
   ...
  
   Donc il trouve bien la ligne et en sort l'adresse IP. Seulement quand
   je vais voir dans les logs de fail2ban, il m'indique bien:
  
   2009-10-25 03:02:23,735 fail2ban.filter : DEBUG  /var/log/auth.log has
   been modified
   2009-10-25 03:02:23,736 fail2ban.filter.datedetector: DEBUG  Sorting
   the template list
  
   Donc il détecte bien que le fichier est modifié, donc je suppose qu'il
   l'analyse avec le regex ci-dessus, mais il ne banni personne...
 
  Je ne sais pas l'action que tu as choisi ...un oeil sur
  iptables/ip6tables :
 
  % iptables -n -L
  % ip6tables -n -L
 
  Comme teste, demande à un ami de se connecter sur ton IP au port SSH
  (22).
 
 
  @+
  --
  (o_
  (/)_
  S e r g e

 Dans banaction j'ai mit 'shorewall', qui correspond à la valeur par
 defaut contenu dans /etc/fail2ban/action.d/shorewall.conf.

 Dedans on y trouves ces deux lignes (je zappe les commentaires etc):

 actionban = shorewall drop ip
 actionban = shorewall allow ip

 iptables ne contient aucune entrée dans DROP/REJECT concernant une
 adresse IP quelquonque. J'essaye de me connecter moi même à la machine
 distante en me trompant de mot de passe, et comme dit précédemment, il
 détecte que le fichier de log est modifié mais ne fais rien.

 J'ai même tenté avec 'iptables-multiport' comme action, mais idem, c'est
 comme s'il n'essayait même pas d'éxécuté l'action, pusique rien n'est
 logé, aucune erreur rien...

 Si vous voulez essayer, voici l'ip de la machine: 91.121.52.49 / 22

 Cela pourrait t'il venir du fait que je sois en même temps connecté en
 ssh ? Et que du coup il ne banni pas quelqu'un déjà connecté?

Comme je disais: que dissent iptables et ip6tables? 

% iptables -n -L
% ip6tables -n -L

De là tu connaitras la config de shorewall et la nouvelle de Fail2Ban. Pour le 
reste on verras suivant les retours de iptables et ip6tables.

@+
PS: on ne donne pas son IP sur une liste même sur Debian.
PS: on poste sur la liste, pas en double ( liste + privée ).
-- 
(o_
(/)_
S e r g e

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: fail2ban / ssh dans Lenny: Ne fonctionne pas

2009-10-25 Par sujet Merwin

Voici le retour iptables:

Chain INPUT (policy DROP)
target prot opt source   destination 
fail2ban-pam-generic  tcp  --  0.0.0.0/00.0.0.0/0   
ACCEPT all  --  0.0.0.0/00.0.0.0/0   
eth0_inall  --  0.0.0.0/00.0.0.0/0   
ACCEPT all  --  0.0.0.0/00.0.0.0/0   state
RELATED,ESTABLISHED 
Reject all  --  0.0.0.0/00.0.0.0/0   
LOGall  --  0.0.0.0/00.0.0.0/0   LOG flags 0
level 6 prefix `Shorewall:INPUT:REJECT:' 
reject all  --  0.0.0.0/00.0.0.0/0   

Chain FORWARD (policy DROP)
target prot opt source   destination 
eth0_fwd   all  --  0.0.0.0/00.0.0.0/0   
ACCEPT all  --  0.0.0.0/00.0.0.0/0   state
RELATED,ESTABLISHED 
Reject all  --  0.0.0.0/00.0.0.0/0   
LOGall  --  0.0.0.0/00.0.0.0/0   LOG flags 0
level 6 prefix `Shorewall:FORWARD:REJECT:' 
reject all  --  0.0.0.0/00.0.0.0/0   

Chain OUTPUT (policy DROP)
target prot opt source   destination 
ACCEPT all  --  0.0.0.0/00.0.0.0/0   
eth0_out   all  --  0.0.0.0/00.0.0.0/0   
ACCEPT all  --  0.0.0.0/00.0.0.0/0   state
RELATED,ESTABLISHED 
Reject all  --  0.0.0.0/00.0.0.0/0   
LOGall  --  0.0.0.0/00.0.0.0/0   LOG flags 0
level 6 prefix `Shorewall:OUTPUT:REJECT:' 
reject all  --  0.0.0.0/00.0.0.0/0   

Chain Drop (2 references)
target prot opt source   destination 
reject tcp  --  0.0.0.0/00.0.0.0/0   tcp
dpt:113 
dropBcast  all  --  0.0.0.0/00.0.0.0/0   
ACCEPT icmp --  0.0.0.0/00.0.0.0/0   icmp type 3
code 4 
ACCEPT icmp --  0.0.0.0/00.0.0.0/0   icmp type
11 
dropInvalid  all  --  0.0.0.0/00.0.0.0/0   
DROP   udp  --  0.0.0.0/00.0.0.0/0   multiport
dports 135,445 
DROP   udp  --  0.0.0.0/00.0.0.0/0   udp
dpts:137:139 
DROP   udp  --  0.0.0.0/00.0.0.0/0   udp spt:137
dpts:1024:65535 
DROP   tcp  --  0.0.0.0/00.0.0.0/0   multiport
dports 135,139,445 
DROP   udp  --  0.0.0.0/00.0.0.0/0   udp
dpt:1900 
dropNotSyn  tcp  --  0.0.0.0/00.0.0.0/0   
DROP   udp  --  0.0.0.0/00.0.0.0/0   udp spt:53 

Chain Reject (4 references)
target prot opt source   destination 
reject tcp  --  0.0.0.0/00.0.0.0/0   tcp
dpt:113 
dropBcast  all  --  0.0.0.0/00.0.0.0/0   
ACCEPT icmp --  0.0.0.0/00.0.0.0/0   icmp type 3
code 4 
ACCEPT icmp --  0.0.0.0/00.0.0.0/0   icmp type
11 
dropInvalid  all  --  0.0.0.0/00.0.0.0/0   
reject udp  --  0.0.0.0/00.0.0.0/0   multiport
dports 135,445 
reject udp  --  0.0.0.0/00.0.0.0/0   udp
dpts:137:139 
reject udp  --  0.0.0.0/00.0.0.0/0   udp spt:137
dpts:1024:65535 
reject tcp  --  0.0.0.0/00.0.0.0/0   multiport
dports 135,139,445 
DROP   udp  --  0.0.0.0/00.0.0.0/0   udp
dpt:1900 
dropNotSyn  tcp  --  0.0.0.0/00.0.0.0/0   
DROP   udp  --  0.0.0.0/00.0.0.0/0   udp spt:53 

Chain all2all (0 references)
target prot opt source   destination 
ACCEPT all  --  0.0.0.0/00.0.0.0/0   state
RELATED,ESTABLISHED 
Reject all  --  0.0.0.0/00.0.0.0/0   
LOGall  --  0.0.0.0/00.0.0.0/0   LOG flags 0
level 6 prefix `Shorewall:all2all:REJECT:' 
reject all  --  0.0.0.0/00.0.0.0/0   

Chain dropBcast (2 references)
target prot opt source   destination 
DROP   all  --  0.0.0.0/00.0.0.0/0   PKTTYPE =
broadcast 
DROP   all  --  0.0.0.0/00.0.0.0/0   PKTTYPE =
multicast 

Chain dropInvalid (2 references)
target prot opt source   destination 
DROP   all  --  0.0.0.0/00.0.0.0/0   state
INVALID 

Chain dropNotSyn (2 references)
target prot opt source   destination 
DROP   tcp  --  0.0.0.0/00.0.0.0/0   tcp flags:!
0x17/0x02 

Chain dynamic (2 references)
target prot opt source   destination 

Chain eth0_fwd (1 references)
target prot opt source   destination 
dynamicall  --  0.0.0.0/00.0.0.0/0   state
INVALID,NEW 
smurfs all  --  0.0.0.0/0

Re: fail2ban / ssh dans Lenny: Ne fonctionne pas

2009-10-25 Par sujet Merwin

Le dimanche 25 octobre 2009 à 15:23 +0100, S e r g e a écrit :
  Donc pour résumer: CA FONCTIONNE!
  Alors question: Pourquoi ça ne marche pas quand je le fais de chez moi
  vers mon serveur (distant!)? Est-ce parceque je suis déjà connecté à la
  machine via un autre terminal?
 
 NOTE: le teste dois être une connexion sur SSH REFUSE . Or si tu es connecté 
 sur une console ton teste ne peut pas aboutir. Tu dois te déconnecter, PUIS 
 établir un teste erroné.  De là ton IP serat bloqué un temps, en passant, 
 allonger le temps à 30 minutes est très bien.
 
 @+

Merci pour tout, en fait ça marchait très bien, ce sont juste mes tests
qui étaient faussés... merci encore Serge!

Donc pour récapituler: Si vous voulez testez, déconnectez-vous
totalement de la machine avant de faire des essais!

Bonne journée à tous,
T.D

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: fail2ban / ssh dans Lenny: Ne fonctionne pas

2009-10-25 Par sujet S e r g e

Le Sunday 25 October 2009 15:30:10 Merwin, vous avez écrit :
 Le dimanche 25 octobre 2009 à 15:23 +0100, S e r g e a écrit :
   Donc pour résumer: CA FONCTIONNE!
   Alors question: Pourquoi ça ne marche pas quand je le fais de chez moi
   vers mon serveur (distant!)? Est-ce parceque je suis déjà connecté à la
   machine via un autre terminal?
 
  NOTE: le teste dois être une connexion sur SSH REFUSE . Or si tu es
  connecté sur une console ton teste ne peut pas aboutir. Tu dois te
  déconnecter, PUIS établir un teste erroné.  De là ton IP serat bloqué un
  temps, en passant, allonger le temps à 30 minutes est très bien.
 
  @+

 Merci pour tout, en fait ça marchait très bien, ce sont juste mes tests
 qui étaient faussés... merci encore Serge!

 Donc pour récapituler: Si vous voulez testez, déconnectez-vous
 totalement de la machine avant de faire des essais!

 Bonne journée à tous,
 T.D

En effet tout était parfait :-)  ...configuré comme un chef!

@ toi aussi bonne journée.

-- 
(o_
(/)_
S e r g e

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: fail2ban et proftpd

2009-02-06 Par sujet Revolver Onslaught

Hello,

Finalement, je viens de trouver la solution: installer le backport de fail2ban.
http://www.backports.org/dokuwiki/doku.php?id=instructions

Le fichier de fail2ban pour proftpd du package corrige ces problèmes.

En espérant que ça puisse en aider d'autres...

R.O.

On Wed, Feb 4, 2009 at 3:13 PM, Revolver Onslaught
revolver.onslau...@gmail.com wrote:
 Bonjour à tous,

 Ma regex fournie avec fail2ban ne fonctionnait pas avec proftpd. J'ai
 donc fait un tour sur Google (pendant 2 heures) mais malheureusement,
 ça ne fonctionne toujours pas.

 Voici les regex pour proftpd:
 failregex = \(\S+\[HOST\]\)[: -]+ USER \S+: no such user found from
 \S+ \[[0-9.]+\] to \S+:\S+$
\(\S+\[HOST\]\)[: -]+ USER \S+ \(Login failed\):
 Incorrect password\.$
\(\S+\[HOST\]\)[: -]+ SECURITY VIOLATION: \S+ login attempted\.$
\(\S+\[HOST\]\)[: -]+ Maximum login attempts \(\d+\) exceeded$

 Lors du restart du service, je vois ceci dans les logs :
 Restarting authentication failure monitor: fail2ban.

 2009-02-04 15:13:55,356 fail2ban.filter : ERROR  Unable to compile
 regular expression \(\S+\[(?:::f{4,6}:)?(?Phost\S+)\]\)[: -]+ USER
 \S+: no such user found from \S+ \[[0-9.]+\] to \S+:\S+$

 L'un d'entre vous a-t-il la bonne regex svp ?

 J'ai également cecci dans les logs:
 iptables -I INPUT -p tcp -m multiport --dports ssh -j fail2ban-ssh
 returned 200
 iptables -I INPUT -p tcp -m multiport --dports ftp -j
 fail2ban-proftpd returned 200
 iptables -I INPUT -p tcp -m multiport --dports ssh -j
 fail2ban-ssh-ddos returned 200
 i
 Une idée ?

 Merci d'avance.

 R.O.

 Fail2Ban v0.7.5
 iptables v1.3.6


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to debian-user-french-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: fail2ban : soucis dans le script de base

2007-08-24 Par sujet Pascal Hambourg


Salut,

Michel Grentzinger a écrit :


Je rencontre un problème avec fail2ban.
Lors de tentatives d'accès illégales en ssh, les logs de fail2ban m'indique 
qu'il bannit bien l'adresse concernée :
2007-08-24 14:51:41,163 fail2ban.actions.action: DEBUG  iptables -L INPUT | 
grep -q fail2ban-ssh returned successfully
2007-08-24 14:51:41,164 fail2ban.actions.action: DEBUG  iptables -I 
fail2ban-ssh 1 -s 217.22.55.50 -j DROP
2007-08-24 14:51:41,172 fail2ban.actions.action: DEBUG  iptables -I 
fail2ban-ssh 1 -s 217.22.55.50 -j DROP returned successfully


Mais lorsque je vérifie avec iptables -L -n, j'ai ceci :
[EMAIL PROTECTED]:~ # iptables -L INPUT -n | grep fail2ban
fail2ban-ssh  tcp  --  0.0.0.0/00.0.0.0/0   tcp dpt:22


AMA il faudrait plutôt vérifier dans la chaîne utilisateur fail2ban-ssh, 
parce que d'après ce que je lis plus haut c'est là que les règles sont 
ajoutées par fail2ban.


# iptables -nL fail2ban-ssh


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et

Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: fail2ban : soucis dans le script de base

2007-08-24 Par sujet Michel Grentzinger

Le vendredi 24 août 2007 15:15, Pascal Hambourg a écrit :
  Mais lorsque je vérifie avec iptables -L -n, j'ai ceci :
  [EMAIL PROTECTED]:~ # iptables -L INPUT -n | grep fail2ban
  fail2ban-ssh  tcp  --  0.0.0.0/00.0.0.0/0   tcp
  dpt:22

 AMA il faudrait plutôt vérifier dans la chaîne utilisateur fail2ban-ssh,
 parce que d'après ce que je lis plus haut c'est là que les règles sont
 ajoutées par fail2ban.

 # iptables -nL fail2ban-ssh

Oui, c'était une partie du problème ! Mais le bannissage ne fonctionnait pas 
non plus !
En fait, c'est lié au bogue n°407561 (
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407561)
une vérification était faite avec la résolution inverse ce qui prennait 
beaucoup de temps car j'ai un script iptables un peu long.

Pour ceux que ça interresse, il faut modifier :
[EMAIL PROTECTED]:~ # diff -u /etc/fail2ban/action.d/iptables.conf*
--- /etc/fail2ban/action.d/iptables.conf2007-08-24 15:06:27.0 
+0200
+++ /etc/fail2ban/action.d/iptables.conf-FIRST  2007-08-24 15:05:23.0 
+0200
@@ -27,7 +27,7 @@
 # Notes.:  command executed once before each fwban command
 # Values:  CMD
 #
-actioncheck = iptables -L INPUT -n | grep -q fail2ban-name
+actioncheck = iptables -L INPUT | grep -q fail2ban-name

Et après tout fonctionne !

Ce bogue ne mériterait-il pas une mise à jour dans stable à la prochaine 
révision ?

-- 
Michel Grentzinger
OpenPGP key ID : B2BAFAFA
Available on http://www.keyserver.net

Re: fail2ban : soucis dans le script de base

2007-08-24 Par sujet mouss


Michel Grentzinger wrote:

Le vendredi 24 août 2007 15:15, Pascal Hambourg a écrit :

Mais lorsque je vérifie avec iptables -L -n, j'ai ceci :
[EMAIL PROTECTED]:~ # iptables -L INPUT -n | grep fail2ban
fail2ban-ssh  tcp  --  0.0.0.0/00.0.0.0/0   tcp
dpt:22

AMA il faudrait plutôt vérifier dans la chaîne utilisateur fail2ban-ssh,
parce que d'après ce que je lis plus haut c'est là que les règles sont
ajoutées par fail2ban.

# iptables -nL fail2ban-ssh


Oui, c'était une partie du problème ! Mais le bannissage ne fonctionnait pas 
non plus !

En fait, c'est lié au bogue n°407561 (
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407561)
une vérification était faite avec la résolution inverse ce qui prennait 
beaucoup de temps car j'ai un script iptables un peu long.


Pour ceux que ça interresse, il faut modifier :
[EMAIL PROTECTED]:~ # diff -u /etc/fail2ban/action.d/iptables.conf*
--- /etc/fail2ban/action.d/iptables.conf2007-08-24 15:06:27.0 
+0200
+++ /etc/fail2ban/action.d/iptables.conf-FIRST  2007-08-24 15:05:23.0 
+0200

@@ -27,7 +27,7 @@
 # Notes.:  command executed once before each fwban command
 # Values:  CMD
 #
-actioncheck = iptables -L INPUT -n | grep -q fail2ban-name
+actioncheck = iptables -L INPUT | grep -q fail2ban-name

Et après tout fonctionne !

Ce bogue ne mériterait-il pas une mise à jour dans stable à la prochaine 
révision ?





euh. pourquoi faire des requetes dns?

Au fait. il faut etre sur de lancer une version recente de fail2ban. Il 
avait un enorme bug:

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-6302
http://www.mail-archive.com/[EMAIL PROTECTED]/msg01806.html

pour vérifier, il suffit de tenter un login en tant que
taratata from 1.2.3.4
et voir si 1.2.3.4 ne se retrouve pas bloqué.

ça donne pas beaucoup confiance tout ça...




--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et

Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: fail2ban et sshd [Résolu]

2007-02-27 Par sujet zelos 414


ça a pas l'air mal du tout.

Par contre, j'ai résolu mon problème. C'était dans la configuration de
fail2ban. Le fichier à parcourir pour scanner les tentatives d'accès
via ssh pointait sur /var/log/sshd.log alors qu'il fallait le pointer
ver /var/log/auth.log

Merci,
Zelos

Le 26/02/07, krusaf[EMAIL PROTECTED] a écrit :

zelos 414 wrote:

 Bonjour,

 Après avoir install fail2ban, je vérifie les fichiers de config et je
 me rends compte que le fichier:

 /etc/fail2ban/filter.d/sshd.conf

 contient:

 failregex = (?:(?:Authentication failure|Failed [-/\w+]+) for(?:
 [iI](?:llegal|nvalid) user)?|[Ii](?:llegal|nvalid) user
 |ROOT LOGIN REFUSED) .*(?: from|FROM) HOST


 Or, ça ne me semble pas coincider avec les logs présents dans
 /var/log/auth.log

 grep sshd /var/log/auth.log

 Feb 25 07:55:37 jupiter sshd[22844]: Invalid user test from
 61.182.211.181
 Feb 25 09:53:48 jupiter sshd[29984]: Invalid user test from
 61.136.143.177
 Feb 25 09:53:57 jupiter sshd[29991]: Invalid user guest from
 61.136.143.177
 Feb 25 09:54:08 jupiter sshd[3]: Invalid user admin from
 61.136.143.177

 Ce qui explique peut-être que fail2ban ne fonctionne guèe pour les
 tentatives d'effraction ssh chez moi.

 Quelqu'un pourraît-il m'indiquer la correction à apporter?

 Merci pour vos réponses,
 Zelos


apt-get install denyhost
^^


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: fail2ban et sshd

2007-02-27 Par sujet Vincent Lefevre

On 2007-02-26 12:37:45 +0100, zelos 414 wrote:
 Quelqu'un pourraît-il m'indiquer la correction à apporter?

Ce serait bien de donner plus d'information, en commençant par les
versions des paquets utilisés (fail2ban et openssh-server).

J'ai l'impression que vu le fichier de config que tu donnes, tu
utilises un fail2ban récent (= 0.7 d'après le fichier NEWS), mais
que tu utilises un ancien serveur SSH (avec la version 4.3p2-8 de
testing, les messages dans auth.log sont différents ici). Alors
c'est sûr, avec la config par défaut de fail2ban, ça risque de ne
pas marcher.

Donc deux solutions:

1. Tu mets à jour tes paquets de façon cohérente, auquel cas tu peux
probablement garder la config par défaut.

2. Tu adaptes la config de fail2ban (ce que Debian fournit, c'est
juste une config par défaut, censée marcher dans les cas standard,
ensuite l'utilisateur fait ce qu'il veut avec).

-- 
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: fail2ban et sshd

2007-02-27 Par sujet zelos 414


Bien vu!
merci mais je n'ai pas eu à toucher le /etc/fail2ban/filter.d/sshd.config
mais juste à renseigner le bon fichier de log de connexions ssh dans
la config de fail2ban.

Zelos

Le 27/02/07, Vincent Lefevre[EMAIL PROTECTED] a écrit :

On 2007-02-26 12:37:45 +0100, zelos 414 wrote:
 Quelqu'un pourraît-il m'indiquer la correction à apporter?

Ce serait bien de donner plus d'information, en commençant par les
versions des paquets utilisés (fail2ban et openssh-server).

J'ai l'impression que vu le fichier de config que tu donnes, tu
utilises un fail2ban récent (= 0.7 d'après le fichier NEWS), mais
que tu utilises un ancien serveur SSH (avec la version 4.3p2-8 de
testing, les messages dans auth.log sont différents ici). Alors
c'est sûr, avec la config par défaut de fail2ban, ça risque de ne
pas marcher.

Donc deux solutions:

1. Tu mets à jour tes paquets de façon cohérente, auquel cas tu peux
probablement garder la config par défaut.

2. Tu adaptes la config de fail2ban (ce que Debian fournit, c'est
juste une config par défaut, censée marcher dans les cas standard,
ensuite l'utilisateur fait ce qu'il veut avec).

--
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: fail2ban et sshd

2007-02-27 Par sujet Vincent Lefevre

On 2007-02-27 14:59:57 +0100, zelos 414 wrote:
 Bien vu!
 merci mais je n'ai pas eu à toucher le /etc/fail2ban/filter.d/sshd.config
 mais juste à renseigner le bon fichier de log de connexions ssh dans
 la config de fail2ban.

Bizarre parce que moi j'ai la bonne config par défaut (et je n'ai donc
rien eu à modifier):

[ssh]

enabled = true
port= ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 6

dans la 0.7.5-2, et

[ssh]

enabled = true
port= ssh,sftp
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 6

dans la 0.7.7-1.

-- 
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: fail2ban et sshd

2007-02-26 Par sujet krusaf

zelos 414 wrote:

 Bonjour,
 
 Après avoir install fail2ban, je vérifie les fichiers de config et je
 me rends compte que le fichier:
 
 /etc/fail2ban/filter.d/sshd.conf
 
 contient:
 
 failregex = (?:(?:Authentication failure|Failed [-/\w+]+) for(?:
 [iI](?:llegal|nvalid) user)?|[Ii](?:llegal|nvalid) user
 |ROOT LOGIN REFUSED) .*(?: from|FROM) HOST
 
 
 Or, ça ne me semble pas coincider avec les logs présents dans
 /var/log/auth.log
 
 grep sshd /var/log/auth.log
 
 Feb 25 07:55:37 jupiter sshd[22844]: Invalid user test from
 61.182.211.181
 Feb 25 09:53:48 jupiter sshd[29984]: Invalid user test from
 61.136.143.177
 Feb 25 09:53:57 jupiter sshd[29991]: Invalid user guest from
 61.136.143.177
 Feb 25 09:54:08 jupiter sshd[3]: Invalid user admin from
 61.136.143.177
 
 Ce qui explique peut-être que fail2ban ne fonctionne guèe pour les
 tentatives d'effraction ssh chez moi.
 
 Quelqu'un pourraît-il m'indiquer la correction à apporter?
 
 Merci pour vos réponses,
 Zelos


apt-get install denyhost
^^


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: fail2ban actif ?

2006-12-23 Par sujet Shams Fantar


Le poulpe qui bloppe ! a écrit :



Pour voir ce qui est blacklisté ou non, (y'a surement mieu) :
iptables -nvL
Comme ca tu as le statut actuel de ton iptables et ses regles actives.


Merci pour vos réponses, fail2ban semble bien fonctionner ;-)

bye

--
Shams Fantar
Support Debian : http://support-debian.homelinux.org
Blog de Scurz : http://sfantar.homelinux.org


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et

Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: fail2ban actif ?

2006-12-22 Par sujet Shams Fantar


patrick heraud a écrit :


Je crois qu'il y a une petite confusion là:
- je dirais plutôt que la traduction serait aproximativement:
statut du moniteur de surveillance des échecs d'authentification: fail2ban 
fonctionne
A mon sens, authentication failure signifie échecs d'authentification et est lié à 
monitor que je traduis par moniteur

Si quelqu'un a mieux...
  



Peut-être mais pourquoi vois-je encore des logs du genre :

Dec 22 16:37:20 * sshd[32655]: Invalid user admin from xxx.xx.xxx.xx
Dec 22 16:37:23 * sshd[32657]: Invalid user test from xxx.xx.xxx.xx
Dec 22 16:37:26 * sshd[32659]: Invalid user testing from xxx.xx.xxx.xx
Dec 22 16:37:29 * sshd[32661]: Invalid user tester from xxx.xx.xxx.xx
Dec 22 16:37:32 * sshd[32663]: Invalid user academy from xxx.xx.xxx.xx

Car à part les bannir à la main, fail2ban ne fait rien là !?


--
Shams Fantar
Support Debian : http://support-debian.homelinux.org
Blog de Scurz : http://sfantar.homelinux.org


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et

Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: fail2ban actif ?

2006-12-22 Par sujet Shams Fantar


Thomas Beugin a écrit :

Ben c'est normal...

Il est bien obligé de voir des tentative se faire pour pouvoir les
blacklister...

Si il ya pas de tentive il va pas blacklister du vents...

si ta reglé fail2ban pour bannir a 3 tentative

tu aura 3 tentative comme ca :
Dec 22 16:37:26 * sshd[32659]: Invalid user testing from 
xxx.xx.xxx.xx
Dec 22 16:37:29 * sshd[32661]: Invalid user tester from 
xxx.xx.xxx.xx
Dec 22 16:37:32 * sshd[32663]: Invalid user academy from 
xxx.xx.xxx.xx


apres il sera banni pour la periode que tu as regle...




Dec 22 16:18:41 * sshd[32609]: Invalid user a from 211.23.152.188
Dec 22 16:18:45 * sshd[32611]: Invalid user b from 211.23.152.188
Dec 22 16:18:56 * sshd[32613]: Invalid user c from 211.23.152.188
Dec 22 16:25:03 * sshd[32636]: Invalid user slim from 211.23.152.188

.mais c'est vrai qu'il y a beaucoup moins de lignes qu'avant avec 
fail2ban


Où peut-on voir les ips bannies ?

bye

--
Shams Fantar
Support Debian : http://support-debian.homelinux.org
Blog de Scurz : http://sfantar.homelinux.org


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et

Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: fail2ban actif ?

2006-12-22 Par sujet Le poulpe qui bloppe !


Le 22/12/06, Shams Fantar [EMAIL PROTECTED] a écrit :


Thomas Beugin a écrit :
 Ben c'est normal...

 Il est bien obligé de voir des tentative se faire pour pouvoir les
 blacklister...

 Si il ya pas de tentive il va pas blacklister du vents...

 si ta reglé fail2ban pour bannir a 3 tentative

 tu aura 3 tentative comme ca :
 Dec 22 16:37:26 * sshd[32659]: Invalid user testing from
 xxx.xx.xxx.xx
 Dec 22 16:37:29 * sshd[32661]: Invalid user tester from
 xxx.xx.xxx.xx
 Dec 22 16:37:32 * sshd[32663]: Invalid user academy from
 xxx.xx.xxx.xx

 apres il sera banni pour la periode que tu as regle...



Dec 22 16:18:41 * sshd[32609]: Invalid user a from 211.23.152.188
Dec 22 16:18:45 * sshd[32611]: Invalid user b from 211.23.152.188
Dec 22 16:18:56 * sshd[32613]: Invalid user c from 211.23.152.188
Dec 22 16:25:03 * sshd[32636]: Invalid user slim from 211.23.152.188

.mais c'est vrai qu'il y a beaucoup moins de lignes qu'avant avec
fail2ban

Où peut-on voir les ips bannies ?

bye

--
Shams Fantar
Support Debian : http://support-debian.homelinux.org
Blog de Scurz : http://sfantar.homelinux.org


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
[EMAIL PROTECTED]





Pour voir ce qui est blacklisté ou non, (y'a surement mieu) :
iptables -nvL
Comme ca tu as le statut actuel de ton iptables et ses regles actives.

Re: fail2ban actif ?

2006-12-21 Par sujet patrick heraud

On Thu, Dec 21, 2006 at 09:45:40PM +0100, Shams Fantar wrote:

 
 Après un /etc/init.d/fail2ban restart, j'ai fait un /etc/init.d/fail2ban 
 status, en voici le résultat :
 
 Status of authentication failure monitor: fail2ban is running
 
 Je peux donc considérer que fail2ban n'est pas actif à cause du failure !
 
Je crois qu'il y a une petite confusion là:
- je dirais plutôt que la traduction serait aproximativement:
statut du moniteur de surveillance des échecs d'authentification: fail2ban 
fonctionne
A mon sens, authentication failure signifie échecs d'authentification et 
est lié à monitor que je traduis par moniteur

Si quelqu'un a mieux...
 J'ai fait un iptables -L pour voir si la règle iptables qu'utilise 
 fail2ban est bien prise en compte :
 
 target prot opt source   destination
 fail2ban-ssh  tcp  --  anywhere anywheretcp dpt:ssh
 

C'est bien la preuve que ça fonctionne.

 Auriez-vous une idée ?
 
 Merci.
 
 -- 
 Shams Fantar
 Support Debian : http://support-debian.homelinux.org
 Blog de Scurz : http://sfantar.homelinux.org
 
 
 -- 
 Lisez la FAQ de la liste avant de poser une question :
 http://wiki.debian.net/?DebianFrench   
 Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
 Reply-To:
 
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact 
 [EMAIL PROTECTED]
 
 ---
 Orange vous informe que cet  e-mail a ete controle par l'anti-virus mail. 
 Aucun virus connu a ce jour par nos services n'a ete detecte.
 
 
 

-- 
---
  Ma clé GPG est disponible sur http://www.keyserver.net (0xD99B1A80)
   1587 B350 1371 C812 39B6 24C1 1BCA 4435 D99B 1A80
---


signature.asc
Description: Digital signature

Re: fail2ban actif ?

2006-12-21 Par sujet Steve

Le jeudi 21 décembre 2006 22:38, patrick heraud a écrit :
 On Thu, Dec 21, 2006 at 09:45:40PM +0100, Shams Fantar wrote:
  Après un /etc/init.d/fail2ban restart, j'ai fait un /etc/init.d/fail2ban
  status, en voici le résultat :
 
  Status of authentication failure monitor: fail2ban is running
 
  Je peux donc considérer que fail2ban n'est pas actif à cause du failure
  !

 Je crois qu'il y a une petite confusion là:
 - je dirais plutôt que la traduction serait aproximativement:
 statut du moniteur de surveillance des échecs d'authentification: fail2ban
 fonctionne A mon sens, authentication failure signifie échecs
 d'authentification et est lié à monitor que je traduis par moniteur

je confirme

 Si quelqu'un a mieux...


  J'ai fait un iptables -L pour voir si la règle iptables qu'utilise
  fail2ban est bien prise en compte :
 
  target prot opt source   destination
  fail2ban-ssh  tcp  --  anywhere anywheretcp
  dpt:ssh

 C'est bien la preuve que ça fonctionne.

exact.


Très belle journée
-- 
s°

85 matches

Mail list logo