12:14 p.m.
I've installed fail2ban on Fedora 15 to block repeated failed ssh
connections. It works great up until logrotate kicks in. When it
rotates /var/log/secure then fail2ban stops noticing failed ssh
attempts. Using fail2ban-client to reload the jail fixes the problem,
but it also causes fail2ban to forget all currently banned IP
addresses. I've found scripts online that will allow for extracting the
current bans before reloading, and then applying them again after, but
that seems pretty extreme. I can't help but think I must be missing
something simple that will get fail2ban to notice that the logs have
been rotated. Has anyone else seeing this issue? I see some reports in
bugzilla about fail2ban, but nothing that is definitely this problem.
Thanks
Mike
4:54 p.m.
On Tue, 2011-10-25 at 16:12 -0400, Mike Wohlgemuth wrote:
I don't see any way to get fail2ban to reopen the log file
without
also forgetting the current ban list.
As I recall, it's supposed to make temporary bans. So does it really
need to keep a ban list forever? You'd be banning things that gave up
long ago. And things that keep on hammering away would auto-ban
themselves quickly enough, again, anyway.
--
[tim@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686
Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.
3:25 p.m.
On 10/25/2011 4:12 PM, Mike Wohlgemuth wrote:
On 10/25/2011 11:12 AM, Mikkel L. Ellertson wrote:
> It looks like you would have to modify the syslog logrotate script
> and add a second command in the postrotate section after it restarts
> syslogd. Does fail2ban accept a SIGHUP to close and reopen the log file?
That was my first thought, but I don't see any way to get fail2ban to
reopen the log file without also forgetting the current ban list.
For what it's worth, I have been using fail2ban and logrotate together
in a vanilla configuration for some time now and have never experienced
this problem. Right now it is running without incident on RHEL 5.7 and
F14. Are you sure you didn't tweak something, either on purpose or by
accident, when you configured things? If you haven't, then perhaps
something has changed and that is why it no longer works as expected.
Tom
3:12 p.m.
On 10/25/2011 11:12 AM, Mikkel L. Ellertson wrote:
It looks like you would have to modify the syslog logrotate script
and add a second command in the postrotate section after it restarts
syslogd. Does fail2ban accept a SIGHUP to close and reopen the log file?
That was my first thought, but I don't see any way to get fail2ban to
reopen the log file without also forgetting the current ban list.
Thanks
Mike
3:10 p.m.
On 10/25/2011 01:23 AM, Andre Speelmans wrote:
Change the config file for logrotate so that it does not create a
new
file, but that it uses copy-and-truncate. The exact syntax is easily
found in the man-page.
Ah, that looks like what I need. I read the man page and spaced on the
implications for that.
Thanks
Mike
11:28 a.m.
It looks like you would have to modify the syslog logrotate script
and add a second command in the postrotate section after it restarts
syslogd. Does fail2ban accept a SIGHUP to close and reopen the log file?
Or make it do copy-truncate, which is meant just for these cases where
a daemon keeps a handle to the file.
--
Kind regards,
André
10:12 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/25/2011 09:07 AM, Andre Speelmans wrote:
> I was referring to the fail2ban RPM. This has to be a problem
for
> just about any installation that uses logrotate.
Most daemons seem to use their own logfile and therefore can use their
own logrotate configuration script in /etc/logrotate.d.
But /var/log/secure is not handled by a specific daemon and thus is
taken care of in the standard logrotate configuration. I don't know
what effects it would give if you try to override it in a more
specific configuration script. Might even not be possible. Or perhaps
it is, hehe.
It is handled by syslogd.
Anyway I think that when you depend on /var/log/secure (or any
generic
logfile), you can't do anything, except informing the users to change
their configuration.
To that extent you can either make it copy-truncate or add a
postrotate script to restart/reload fail2ban.
It looks like you would have to modify the syslog logrotate script
and add a second command in the postrotate section after it restarts
syslogd. Does fail2ban accept a SIGHUP to close and reopen the log file?
Mikkel
- --
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk6m0ekACgkQqbQrVW3JyMRk8gCggt47/wBV7UqswW6D3U4Xrnx2
60oAn3oquksi9g4NKoSGDc7hHYtZtyTV
=KQvl
-----END PGP SIGNATURE-----
9:07 a.m.
I was referring to the fail2ban RPM. This has to be a problem for
just about any installation that uses logrotate.
Most daemons seem to use their own logfile and therefore can use their
own logrotate configuration script in /etc/logrotate.d.
But /var/log/secure is not handled by a specific daemon and thus is
taken care of in the standard logrotate configuration. I don't know
what effects it would give if you try to override it in a more
specific configuration script. Might even not be possible. Or perhaps
it is, hehe.
Anyway I think that when you depend on /var/log/secure (or any generic
logfile), you can't do anything, except informing the users to change
their configuration.
To that extent you can either make it copy-truncate or add a
postrotate script to restart/reload fail2ban.
--
Kind regards,
André
8:37 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/25/2011 12:23 AM, Andre Speelmans wrote:
> It sounds like fail2ban still has the old log file open. You need
to
> have logrotate tell fail2ban that the log file has changed.
Change the config file for logrotate so that it does not create a new
file, but that it uses copy-and-truncate. The exact syntax is easily
found in the man-page.
> Logrotate already does this will other services when it rotates
> their log file. I am surprised the .rpm did not include the files
> for logrotate to automatically sent the proper signal to fail2ban.
/var/log/secure is not a daemon specific file, but a general log-file
and as such does not have a (daemon-) specific rpm. And a general file
can't send signals to all kinds of daemons that may, or may not run on
a system.
I was referring to the fail2ban RPM. This has to be a problem for
just about any installation that uses logrotate.
Mikkel
- --
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk6mu58ACgkQqbQrVW3JyMQW3QCeJqMJhzTQ6iEsAt8Yo/b5h1Yo
ax4AmwVlI7NSLBXarL243k/YJEwl1fWi
=xXE+
-----END PGP SIGNATURE-----
12:23 a.m.
It sounds like fail2ban still has the old log file open. You need to
have logrotate tell fail2ban that the log file has changed.
Change the config file for logrotate so that it does not create a new
file, but that it uses copy-and-truncate. The exact syntax is easily
found in the man-page.
Logrotate already does this will other services when it rotates
their log file. I am surprised the .rpm did not include the files
for logrotate to automatically sent the proper signal to fail2ban.
/var/log/secure is not a daemon specific file, but a general log-file
and as such does not have a (daemon-) specific rpm. And a general file
can't send signals to all kinds of daemons that may, or may not run on
a system.
6:53 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/24/2011 12:14 PM, Mike Wohlgemuth wrote:
I've installed fail2ban on Fedora 15 to block repeated failed ssh
connections. It works great up until logrotate kicks in. When it
rotates /var/log/secure then fail2ban stops noticing failed ssh
attempts. Using fail2ban-client to reload the jail fixes the problem,
but it also causes fail2ban to forget all currently banned IP
addresses. I've found scripts online that will allow for extracting the
current bans before reloading, and then applying them again after, but
that seems pretty extreme. I can't help but think I must be missing
something simple that will get fail2ban to notice that the logs have
been rotated. Has anyone else seeing this issue? I see some reports in
bugzilla about fail2ban, but nothing that is definitely this problem.
Thanks
Mike
It sounds like fail2ban still has the old log file open. You need to
have logrotate tell fail2ban that the log file has changed.
Logrotate already does this will other services when it rotates
their log file. I am surprised the .rpm did not include the files
for logrotate to automatically sent the proper signal to fail2ban.
Mikkel
- --
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk6l+nwACgkQqbQrVW3JyMQXbwCfWwWQXNCmsHlIriPqHy1FALI9
asQAn1qsjxbOzlxOT3yn81XHj5bR5aLn
=vGsK
-----END PGP SIGNATURE-----
1:17 p.m.
On Mon, Oct 24, 2011 at 10:14 AM, Mike Wohlgemuth <mjw(a)woogie.net> wrote:
I've installed fail2ban on Fedora 15 to block repeated failed
ssh
connections. It works great up until logrotate kicks in. When it
rotates /var/log/secure then fail2ban stops noticing failed ssh
attempts. Using fail2ban-client to reload the jail fixes the problem,
but it also causes fail2ban to forget all currently banned IP
addresses. I've found scripts online that will allow for extracting the
current bans before reloading, and then applying them again after, but
that seems pretty extreme. I can't help but think I must be missing
something simple that will get fail2ban to notice that the logs have
been rotated. Has anyone else seeing this issue? I see some reports in
bugzilla about fail2ban, but nothing that is definitely this problem.
Thanks
Mike
--
Hi
This does not address your problem directly.
I use a program called denyhosts for blocking ssh attempts. It creates a
list in /etc/hosts.deny.
Great program.
Good luck
Marvin
1:44 p.m.
On Mon, Oct 24, 2011 at 20:17, Marvin Kosmal <mkosmal(a)gmail.com> wrote:
Hi
This does not address your problem directly.
I use a program called denyhosts for blocking ssh attempts. It creates a
list in /etc/hosts.deny.
Great program.
+1 to denyhosts.
Good luck
Marvin
--
Suvayu
Open source is the future. It sets us free.
4577
days inactive
4578
days old
12 comments
7 participants
participants (7)
-
Andre Speelmans -
Marvin Kosmal -
Mike Wohlgemuth -
Mikkel L. Ellertson -
Suvayu Ali -
Tim -
Tom Rivers