I have been using centos 6 in a virtualized system for a few months now. Took a while to batten down the hatches with postfix, rbls, and to use fail2ban correctly. The mailserver for my website(s) are located on the http server as well..an 'all in one' server. DNS servers are separated.
My two sites, and their emails addresses (1 for each) have been around for 10 and 15 years respectively. One site was a business site, one was news and politics...both were very busy at one point, thus 'on the radar' of hackers and spammers.
I decided to see what I could do with my system to prevent hacks and spams in regards to email and brute force attacks on all systems except for my web apps (which are down right now and in development).
Fail2ban is really good at the brute force, assuming it is just one ip and not all attempts are at once. Thus it works on script kiddies but I do not think it would work well on a dedicated hack attempt by a serious individual or group.
But I am using fail2ban to auto ban ips regarding spam.
As far as spam, very little gets through now. A few a day. Between blacklists, my own blacklist of commercial spammers, stringent settings of postfix the actual spam that gets through is small. But it still gets through.
I was using fail2ban on attempts that numbered 3 or more that ended in 5xx replies from my server. I would block for 10 minutes. I found I was blocking about 800 ips a day on one server, half that on the other. I did notice that there were a ton of attempts that were under 3. Lots of 2's and a ton of 1's.
So a couple weeks ago (not sure when I started) I decided to try blocking any 5xx reply by IP. This is a private server and just my own mail comes to it, so I am not worried too much about false positives or other effects.
------------------------------------------------ So what happened?
The ips jumped up considerably, to 1,500 to 1,700 a day banned on one server, about 1000 on the other. What is interesting in those numbers is they are constant. Every week day I can count on about 1500 banned ips on one, 1000 on the other, give or take.
What really changed was the mail servers sending mail that got through the restrictions, but were sending to non existent addresses. A majority (like 80%) were from yahoo. This was a sudden change. It was not like this before. Yahoo spammed like crazy. And they got the mailserver ip banned.
10 to 20 emails a day from yahoo mail servers, going to non existent emails. Where before it would be one or two. The yahoo mails got bigger every day until they started waning (probably due to ip banning).
The mail that actually got through all of this was 50% free mail (yahoo, msn/live, some aol, etc) Yahoo being the biggest.
Another thing I noticed. When I started adding domains to my 'blacklist of commercial senders', legitimate or not, I started to get yahoo mails with references inside the mails to many of the illegitimate sites that were coming from the UCE's I had blocked.
It is quite interesting to watch this process. More interesting that no matter how strict or lax I make the system there will be the same number of attempted mails sent to my server. (give or take a few hundred).
If I unban all the ips, which I did once, there was a one day bump up, then it leveled off to the same amount of individual attemtps (not counting the same attempt being tried again).
I have 35,000 ips blocked right now and nothing changed...except yahoo spam.
Spamassassin I use, but only for level 10 or more spam...it is deleted. I found all of these over the last few months to be the kind with attachments, probably viruses.
------------------------------------------------------------------------- What Have I learned?
I have learned a large number of attempts are from ISP's and not websites.
I have learned that ISP's will not do anything at all, ever, about this. (someone trying to send 1 million mails a day might be suspicious, but they ignore it)
I have learned a large majority of 'hosts' are technically challenged small business owners who have no sys admin knowledge. Those hosts spew spam bots
I have learned the chinese have really taken a liking to play with my server, possibly for training purposes. My server is a hit in beijing and some other province I cannot spell.
---------------------------------------------------------- What can be done?
Not much. If the isp's do nothing, and the technology is not available to datacenters and hosts, there is not much I can do at all. Complaining to an isp or host would take 24 hours a day of messages, 99% which would be ignored.
There is a consideration for the scumbags that call themselves legitimate mailers, like vocus.com. They are in the US, as I am. I am considering going to small claims for some of these spam attempts. I cannot use the can-spam act, since they are technically not in violation.
However, I could use the logs and attempts, copies of emails and phone calls telling them to stop, and sue them for a small dedicated denial of service attack, use of my bandwidth, harassment of my server and business.
Would I win? Probably. Would I ever get money from them? Most likely not.
Quoting Bob Hoffman bob@bobhoffman.com:
I have been using centos 6 in a virtualized system for a few months now. Took a while to batten down the hatches with postfix, rbls, and to use fail2ban correctly.
Thanks for this,Bob. I'm having trouble making fail2ban work in my Centos 5.8 box. Would you be willing to share your fail2ban setup? Jails.conf would be most welcome.
Dave
On 6/15/2012 8:44 PM, Dave Stevens wrote:
Quoting Bob Hoffmanbob@bobhoffman.com:
I have been using centos 6 in a virtualized system for a few months now. Took a while to batten down the hatches with postfix, rbls, and to use fail2ban correctly.
Thanks for this,Bob. I'm having trouble making fail2ban work in my Centos 5.8 box. Would you be willing to share your fail2ban setup? Jails.conf would be most welcome.
Dave
I will try to post some notes tomorrow, but I think I posted a how to last month or so on this list.
1- you must use gamin as the setting or the log rotations will make fail2ban fail 2- you must add a sleep command in the config files in usr/share/fail2ban or using more than one jail can cause a failure of 1 or more jails when starting up..(too fast for netfilter version that comes with centos 6)
I do not have my notes with me now, but without those two things it will not work...period...at least not correctly. If you search google you can find the sleep command...but there are like 7 different ways people did it for different linux distros and versions of fail2ban.
the jails are not so bad...
I will post what I figured out tomorrow after work..
It is a very trying program. It is a neat idea though.
Hello Bob,
On Sat, 2012-06-16 at 22:47 -0400, Bob Hoffman wrote:
1- you must use gamin as the setting or the log rotations will make fail2ban fail
I noticed the failing of fail2ban after rotating the logs too. Supposedly it works fine on CentOS 5 (from an IRC chat on #fedora-epel(?)), but on CentOS 6 fail2ban will stop banning after log rotation even though it should handle log rotation transparently.
However, you can fix your logrotate configuration to restart fail2ban after rotating the logs. Sadly that will remove current bans, but at least new bans will be added:
(mind the line wraps)
$ cat /etc/logrotate.d/syslog /var/log/cron /var/log/maillog /var/log/messages /var/log/secure /var/log/spooler { sharedscripts postrotate /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true # reload fail2ban after log rotation /usr/bin/fail2ban-client -x reload > /dev/null endscript }
Regards, Leonard.
On 06/17/2012 10:16 AM, Leonard den Ottolander wrote:
Hello Bob,
On Sat, 2012-06-16 at 22:47 -0400, Bob Hoffman wrote:
1- you must use gamin as the setting or the log rotations will make fail2ban fail
I noticed the failing of fail2ban after rotating the logs too. Supposedly it works fine on CentOS 5 (from an IRC chat on #fedora-epel(?)), but on CentOS 6 fail2ban will stop banning after log rotation even though it should handle log rotation transparently.
However, you can fix your logrotate configuration to restart fail2ban after rotating the logs. Sadly that will remove current bans, but at least new bans will be added:
(mind the line wraps)
$ cat /etc/logrotate.d/syslog /var/log/cron /var/log/maillog /var/log/messages /var/log/secure /var/log/spooler { sharedscripts postrotate /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true # reload fail2ban after log rotation /usr/bin/fail2ban-client -x reload> /dev/null endscript }
Regards, Leonard.
I have been following this thread and I am interested to know what kinda of notice your getting to know fail2ban has crashed on a logrotate. I just did a force rotate and the only thing fail2ban did was restart.
I am using Centos 6.2 + postfix + fail2ban-0.8.2-3.el6.rf
TIA
On Sun, 2012-06-17 at 10:32 -0400, Mail Lists wrote:
I have been following this thread and I am interested to know what
kinda of notice your getting to know fail2ban has crashed on a logrotate. I just did a force rotate and the only thing fail2ban did was restart.
There's no notice. For some reason it cannot find the log file(s) it's tracking anymore after a log rotate and stops adding IPs. The way I noticed this was happening is because fail2ban started to get awfully quiet (no ban mails).
I am using Centos 6.2 + postfix + fail2ban-0.8.2-3.el6.rf
The problem I'm seeing is with the EPEL build for CentOS 6. I don't know if the RF build is also affected.
Regards, Leonard.
On 06/17/2012 10:38 AM, Leonard den Ottolander wrote:
The problem I'm seeing is with the EPEL build for CentOS 6. I don't know if the RF build is also affected. Regards, Leonard.
From what I am seeing the RF build is not effected. within seconds of my forced rotate I got notice of another ban. Thanks for the info..
On 6/17/2012 12:09 PM, Mail Lists wrote:
On 06/17/2012 10:38 AM, Leonard den Ottolander wrote:
The problem I'm seeing is with the EPEL build for CentOS 6. I don't know if the RF build is also affected. Regards, Leonard.
From what I am seeing the RF build is not effected. within seconds
of my forced rotate I got notice of another ban. Thanks for the info..
force rotate will not trigger the issue with fail2ban.... setup your logrotate file to go daily and see what happens the next day.
On 6/17/2012 12:32 PM, bob wrote:
force rotate will not trigger the issue with fail2ban.... setup your logrotate file to go daily and see what happens the next day.
to clarify, it is the rotation of the log files fail2ban is looking at that is the issue, not fail2ban rotating its own logs. without gamin being used with centos 6 it will get lost and stay on the old log file that was rotated..thus never logging anything again until restart/reload of fail2ban client
Here is what I had to do to make fail2ban work with centos 6, fail2ban from epel This is a long letter and no html to make it read better. It deals with failed jails during start, loss of ban/unban after systems logrotates files, errors in jails, sasl errors, logging file correctly to work with fail2ban and logwatch, fail2ban logrotate.
I hope this helps others, it was a real bear and the first program/rpm I used that really does not work very well as set up. (a update was pushed a few weeks back, not sure how this affects anything below...mine still works as is.) Forgive me if I left something out.
first I added these programs to the EPEL repo ( I do not allow any except those I use, so I use the following to limit the repo.)
includepkgs= fail2ban shorewall shorewall-core python-inotify gamin-python
Fail2ban has recently been updated on the epel repo and shorewall-core is now needed too, this is new. How the new updates affects any of the below is beyond me, but I doubt it changed anything.
1st issue ------------------ /etc/fail2ban/jail.conf change line 39 to backend = gamin
Without this fail2ban will ignore log rotations by logrotate and stay on the old file in your jails. This was needed or it failed. No errors, nothing. Force log rotate did not make this happen, only the program running each morning did it. I changed mine to a daily rotate of /var/log/secure,vsftpd.log, etc... to test this. Without gamin it failed every time.
(also you need to add this) line 16 (add your ip (or ip block?) after the 127 ip) Use a space between them all. ignoreip = 127.0.0.1 yourip
2nd issue ------------------- with more than one jail you can (and will) get chances of errors when starting fail2ban. Some people seem to attribute it centos 6 having an older version of netfilter. The program goes to fast for iptables and chokes setting up the chains. Sometimes they all go on, most times I would lose one to two chains during each restart of fail2ban.
You have to have debug with at least 'info' to see these errors. When stopping you will get a ton of these errors too, but they seem to have no effect on anything.
To stop these errors and allow all jails to start properly you have to add a sleep line deep in the code. I have not tested since the update to see if this was overwritten but will do that this week.
/usr/bin/fail2ban-client
Find the following code and add the time.sleep(0.1) in there as I have. You need to press the tab 3 times to indent it, python pays attention to white space, it will choke if you do not do this.
add sleep command into the following, (tab three times) starts at line 142 def __processCmd(self, cmd, showRet = True): beautifier = Beautifier() for c in cmd: time.sleep(0.1) beautifier.setInputCmd(c) try:
This lets netfilter catch up with the fail2ban client and allows all jails to get started properly. If you only use one jail this would not be needed, but each one after that offers a chance of not being turned on.
3rd issue ------------------- The whole log thing is borked. if you try to use fail2ban.log, fail2ban itself will choke on it. If you try to use the repo's set up of using /var/log/messages than logwatch will get borked on it. However, if you set it all to /var/log/fail2ban as the log file, it will work.
No matter which way you want it, logwatch, fail2ban, and logrotate all point to different files for logging and it is a real mess.
Here is what I did to make it log and allow logrotate to work with it.
/etc/fail2ban/fail2ban.conf line 25 logtarget = /var/log/fail2ban
/etc/logrotate.d/fail2ban Below I changed the logtarget and stopped the 'restart' the repo wanted. Thus it will keep running day after day.
/var/log/fail2ban { missingok notifempty rotate 7 create 0600 root root postrotate /usr/bin/fail2ban-client set logtarget /var/log/fail2ban 2> /dev/null || true endscript }
finally for logwatch /usr/share/logwatch/default.conf/logfiles/fail2ban.conf LogFile = fail2ban Archive = fail2ban-*
------------------------------------------------------------------------------------------------------------------ jails I set up...this is gonna be quick with little info, still writing notes for the book on this one I lowered the times in them for this letter, but mine are much higher. I separated the ports for each for testing and safety. You could make all the ports blocked if you wanted too.
The first ssh in the repo is enabled by default I think. Make sure if you use these you check all others to make sure they are not enabled.
[ssh-iptables]
enabled = true filter = sshd action = iptables[name=SSH, port="22444", protocol=tcp] logpath = /var/log/secure maxretry = 2 bantime = 3600
[apache-tcp] enabled = true filter = apache-auth bantime = 10000 action = iptables[name=ApacheAuth, port="80", protocol=tcp] logpath = /var/log/httpd/error_log maxretry = 3
[apache-ssl] enabled = true filter = apache-auth-ssl bantime = 10000 action = iptables[name=ApacheAuthSsl, port="443", protocol=tcp] logpath = /var/log/httpd/ssl_error_log maxretry = 3
[vsftpd-iptables] enabled = true filter = vsftpd action = iptables[name=VSFTPD, port="5000", protocol=tcp] logpath = /var/log/vsftpd.log maxretry = 3 bantime = 3600
[Dovecot] enabled = true filter = dovecot bantime = 3600 maxretry = 2 action = iptables-multiport[name=DOVECOT, port="25,465,993,995", protocol=tcp] logpath = /var/log/maillog
[Postfix] enabled = true filter = postfix maxretry = 2 bantime = 3600 findtime = 3600 action = iptables-multiport[name=POSTFIX, port="25,465,993,995", protocol=tcp] logpath = /var/log/maillog [Postfix-sasl] enabled = true filter = sasl maxretry = 4 bantime = 3600 findtime = 3600 action = iptables-multiport[name=POSTFIX-SASL, port="25,465,993,995", protocol=tcp] logpath = /var/log/maillog
There was not one for dovecot, so I had to make one.. I do not think it is needed though, but I added it anyway (both go to maillog, but I figured I could do things with the jail later)
Here are some files I had to add to make the above jails work. ##################################### make a new file called dovecot.conf as below /etc/fail2ban/filter.d/dovecot.conf
[Definition] # Option: failregex # Notes.: regex to match the password failures messages in the logfile. The # host must be matched by a group named "host". The tag "<HOST>" can # be used for standard IP/hostname matching. # Values: TEXT #
failregex = (?: pop3-login|imap-login): (?:Authentication failure|Aborted login (auth failed|Aborted login (tried to use disabled|Disconnected (auth failed).*rip=(?P<host>\S*),.*
# Option: ignoreregex # Notes.: regex to ignore. If this regex matches, the line is ignored. # Values: TEXT # ignoreregex =
####################################
for my apache auth I added this one from someone online too
####################### make a new file /etc/fail2ban/filter.d/apache-auth-ssl.conf # Fail2Ban configuration file # # Author: Cyril Jaquier # # $Revision: 728 $ #
[Definition]
# Option: failregex # Notes.: regex to match the password failure messages in the logfile. The # host must be matched by a group named "host". The tag "<HOST>" can # be used for standard IP/hostname matching and is only an alias for # (?:::f{4,6}:)?(?P<host>[\w-.^_]+) # Values: TEXT # failregex = [[]client <HOST>[]] user .* authentication failure [[]client <HOST>[]] user .* not found [[]client <HOST>[]] user .* password mismatch
# Option: ignoreregex # Notes.: regex to ignore. If this regex matches, the line is ignored. # Values: TEXT # ignoreregex = ###############################
for postfix I had to add somethings to block spam. I had made some errors to default to 550 to lower spam attempts too.
/etc/fail2ban/filter.d/postfix.conf failregex = reject: RCPT from (.*)[<HOST>]: 554 reject: RCPT from (.*)[<HOST>]: 550 reject: RCPT from (.*)[<HOST>]: 504
(still need to add a 501 in there too for invalid names)
############################################# for the sasl/postfix to work properly some changes were made, this is my file. The one that came with the repo will not work. At least it did not work for me.
/etc/fail2ban/filter.d/sasl.conf
this is my file
# Fail2Ban configuration file # # Author: Yaroslav Halchenko # # $Revision: 728 $ #
[Definition]
# Option: failregex # Notes.: regex to match the password failures messages in the logfile. The # host must be matched by a group named "host". The tag "<HOST>" can # be used for standard IP/hostname matching and is only an alias for # (?:::f{4,6}:)?(?P<host>[\w-.^_]+) # Values: TEXT # failregex = (?i): warning: [-._\w]+[<HOST>]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(: [A-Za-z0-9+/]*={0,2})?$ (?i): warning: [-._\w]+[<HOST>]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed: Invalid authentication mechanism (?i): warning: [-._\w]+[<HOST>]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed.* # Option: ignoreregex # Notes.: regex to ignore. If this regex matches, the line is ignored. # Values: TEXT # ignoreregex =
###################################################
here is my iptables with some things taken out for security...lol
############################################## [root@ ~]# iptables -L -n
Chain INPUT (policy ACCEPT) target prot opt source destination fail2ban-VSFTPD tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:xx fail2ban-DOVECOT tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,993,995 fail2ban-POSTFIX tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,993,995 fail2ban-ApacheAuthSsl tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 fail2ban-ApacheAuth tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 fail2ban-SSH tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22444 fail2ban-POSTFIX-SASL tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,993,995 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:25 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:465 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:993 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:995 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:xx ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED tcp dpt:xx ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW,ESTABLISHED tcp dpt:xx ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpts:xx:xx REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT) target prot opt source destination REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT) target prot opt source destination
Chain fail2ban-ApacheAuth (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain fail2ban-ApacheAuthSsl (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain fail2ban-DOVECOT (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain fail2ban-POSTFIX (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain fail2ban-POSTFIX-SASL (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain fail2ban-SSH (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain fail2ban-VSFTPD (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0
Hello Bob,
On Sun, 2012-06-17 at 23:41 -0400, Bob Hoffman wrote:
/etc/fail2ban/jail.conf change line 39 to backend = gamin
Without this fail2ban will ignore log rotations by logrotate and stay on the old file in your jails.
Polling doesn't work with python >= 2.6. I haven't tested if you will actually get a warning when using backend = polling, but there's some code in asyncserver.py disables polling. Using backend = auto will fall back to using pyInotify. This backend causes the issue with fail2ban not noticing the log files having been rotated. Might be an issue with too few events being passed to fail2ban. Couldn't quite work it out yet.
I have reported the issue: https://bugzilla.redhat.com/show_bug.cgi?id=833056
with more than one jail you can (and will) get chances of errors when starting fail2ban. Some people seem to attribute it centos 6 having an older version of netfilter. The program goes to fast for iptables and chokes setting up the chains.
This issue is known in Debian's bug tracker which also provides a reference to a patch that you might want to check out.
I have reported the issue: https://bugzilla.redhat.com/show_bug.cgi?id=833046
You have to have debug with at least 'info' to see these errors.
They are reported as errors, so I think you might be mistaken here. If not then there's a bug with the error reporting :p .
When stopping you will get a ton of these errors too, but they seem to have no effect on anything.
Those errors are caused by the chains to be removed not actually being there.
add sleep command into the following
That won't work with the current version. The code has changed significantly. See the patch mentioned in the bugzilla entry above.
The whole log thing is borked. if you try to use fail2ban.log, fail2ban itself will choke on it.
Haven't run into this one yet. Perhaps you can report that via https://bugzilla.redhat.com/ (you can find EPEL under Fedora).
Regards, Leonard.
On 6/18/2012 9:53 AM, Leonard den Ottolander wrote:
Hello Bob,
On Sun, 2012-06-17 at 23:41 -0400, Bob Hoffman wrote:
/etc/fail2ban/jail.conf change line 39 to backend = gamin
Without this fail2ban will ignore log rotations by logrotate and stay on the old file in your jails.
Polling doesn't work with python>= 2.6. I haven't tested if you will actually get a warning when using backend = polling, but there's some code in asyncserver.py disables polling. Using backend = auto will fall back to using pyInotify. This backend causes the issue with fail2ban not noticing the log files having been rotated. Might be an issue with too few events being passed to fail2ban. Couldn't quite work it out yet.
I have reported the issue: https://bugzilla.redhat.com/show_bug.cgi?id=833056
with more than one jail you can (and will) get chances of errors when starting fail2ban. Some people seem to attribute it centos 6 having an older version of netfilter. The program goes to fast for iptables and chokes setting up the chains.
This issue is known in Debian's bug tracker which also provides a reference to a patch that you might want to check out.
I have reported the issue: https://bugzilla.redhat.com/show_bug.cgi?id=833046
You have to have debug with at least 'info' to see these errors.
They are reported as errors, so I think you might be mistaken here. If not then there's a bug with the error reporting :p .
When stopping you will get a ton of these errors too, but they seem to have no effect on anything.
Those errors are caused by the chains to be removed not actually being there.
add sleep command into the following
That won't work with the current version. The code has changed significantly. See the patch mentioned in the bugzilla entry above.
The whole log thing is borked. if you try to use fail2ban.log, fail2ban itself will choke on it.
Haven't run into this one yet. Perhaps you can report that via https://bugzilla.redhat.com/ (you can find EPEL under Fedora).
Regards, Leonard.
Leonard, The debian and redhat issues seem to be worlds apart. I know as I tried all the fixes and found debian fixes a dead end. Gamin is the only polling that allowed fail2ban to work. No other polling worked after rotate. The errors on shutdown are the same as the errors for startup, when not using sleep. I get one for each jail it kills in iptables.
the sleep command that I presented does prevent the issue on startup. I tried about 10 different ones until that one hit. It does work with centos 6, so far mine is running well. However, since that last updates a few weeks ago I have not restarted it, so will check on it.
The log file issue is due to all three programs wanting to look in a different place for the logfile. You have to pick one and change all other references. Why fail2ban dies looking for fail2ban.log, but works fine looking for a log file named 'fail2ban' has to be something in their code somewhere.
I don't know if this is any bug I would submit to redhat, it seemed to be fail2ban's issue...and each issue I had has been going on for years according to the huge number of pages I went too...including fail2ban's own documents of these various issues.
Now I am afraid to restart it...lol....
Hello Bob,
On Mon, 2012-06-18 at 10:07 -0400, Bob Hoffman wrote:
The debian and redhat issues seem to be worlds apart. I know as I tried all the fixes and found debian fixes a dead end.
I still believe http://sourceforge.net/tracker/?func=detail&aid=2870788&group_id=121... is the issue we are seeing.
http://sourceforge.net/tracker/?func=detail&aid=2857096&group_id=121... might indeed be a different but similar (timing) issue though. The patch added there is for action.py and indeed not relevant to the jail start up issues.
The errors on shutdown are the same as the errors for startup, when not using sleep. I get one for each jail it kills in iptables.
They are similar but not the same (-X instead of -I etc.). I only see errors for jails for which the iptables rules didn't get applied. The rules that didn't get added on start up are being removed but not found which causes the errors on shutdown.
the sleep command that I presented does prevent the issue on startup.
My bad. The patch you mention indeed does apply. I see why I got confused:
$ grep def\ __processCmd * fail2ban-client server/action.py
I overlooked fail2ban-client and thought this had to be applied to action.py. I will give that sleep in fail2ban-client a try.
Could you please provide a url to that patch or add it to the bug report I made? I remember seeing it but forgot to bookmark it.
I don't know if this is any bug I would submit to redhat, it seemed to be fail2ban's issue...
Bugs for EPEL packages have to be reported via Red Hat's bugzilla. Perfectly valid issue to put in their bug tracker, especially since there seems to be not much going on upstream. Even confused where upstream is, there are patches to the SourceForge tree that seem not to have propagated to the now current(?) GitHub repo.
Regards, Leonard.
Hello Bob,
On Mon, 2012-06-18 at 17:03 +0200, Leonard den Ottolander wrote:
I overlooked fail2ban-client and thought this had to be applied to action.py. I will give that sleep in fail2ban-client a try.
I'm glad you pointed out this patch as I had accidently discarded it. Seems indeed to work although sleeping is not quite as clean as actually waiting for the command to finish as is attempted in that patch for action.py (yes different issue). Not even sure if that is possible with client.send(c) in its current form.
Could you please provide a url to that patch or add it to the bug report I made? I remember seeing it but forgot to bookmark it.
Never mind, it's at http://www.fail2ban.org/wiki/index.php/Fail2ban_talk:Community_Portal under "fail2ban.actions.action ERROR on startup/restart".
Regards, Leonard.