I posted this, originally, in the security section. But I haven't had any replys there so I wanted to post here. I have used fail2ban for years with Suse, but I'm having some trouble getting it implemented in Slackware.

Having some problems getting fail2ban to actually properly ban ip's that fail authentication when trying to SSH. Fail2ban client is up and running properly. I am feeding it the correct log file for slackware (/var/log/messages). I made sure to "enable" sshd-iptables in the jail.conf file. Here is a "status" to make sure fail2ban is running:


Then, I'll attempt to log on incorrectly to ssh and fail2ban will recognize the incorrect attempts. It will then ban that IP causing the failure. Here is proof that fail2ban is TRYING to work properly:


As you can see, it banned 192.168.1.3. At least it thought it did... However, I can still connect to my server (192.168.1.2) with no problems. I can still ssh to it, check mail, etc... That address is NOT banned. I have already verified iptables is working by doing a:

"iptables -I INPUT -s 192.168.1.3 -j DROP"

If I do the above commands, 192.168.1.3 is banned. So I know iptables is working if I can manually type that in and get it to work that way.

I dunno what is up. Any one else have any problems?

Also I'm not using Slackware on a regular basis also not using fail2ban here is some tips how you got get behind the reason for fail2ban not doing what it's suppose to be.

Maybe you can get some more info of the fail2ban-server. In a seperate shell start the server with
to have it run in foreground. I bet it'll print some nice logs onto the screen.

Another thing is if you might have an iptables rule where all the clients from the 192.168.0.0/24 network are allowed. This sure should be above the iptables rule from fail2ban. Also I doubt that is the case cause you can ban the ip manualy.
But are you sure fail2ban uses iptables to block access? Maybe it just used the tcpwrapper file /etc/hosts.deny and /etc/hosts.allow.

Hope some of this can get you further.

Biggen,

fail2ban actually uses regex to match the failure message in the logs. Did you check the offending's IP's failure message in logs and see if your fail2ban regex actually matches to that. Check fail-regex option in the config files.

Other problem may be much lower ban time, you can configure the actual time (mins/hrs/days) to ban a particular type of login/cracking attempt.

Thanks for the response. I'm not in front of my server right now so I'll try that command later. I don't believe Slack uses tcpwrapper. And, if I do an "iptables -L" after making sure fail2ban is running, I can see that fail2ban added a chain in iptables so that it can ban and unban when it needs. So it is definately "talking" to iptables.

Yeah, I issued the "regex" command on the fail2ban page that tests the system to make sure it is reading log file properly and it I.D. the IP causing the failures. I'm not in front of my server now, so I can't show the output. When I get home later, I'll post that output.

What is crazy is that I get an email from fail2ban saying it banned the IP and I see a chain showing it banned it, but it simply isn't banned. I'll do the regex command later and copy and paste that here. Then I'll try to incorrectly log onto SSH and get it to ban my client and then copy and paste the chain so that you guys can have a look at it...

Sure does - tcp_wrappers-7.6-i481-1 on a Slackware 12.2 system. From the package :
Not sure this relates to your problem though.

Please do not crosspost threads.

Ummm.. I'm not sure what you expect when I don't get any suggestions in one forum. Of course I am going to try in another forum...

Success!!

Well I figured it out. I forgot that I changed the port on my sshd to a nonstandard port, but in the jail.conf, I still had the port listed as "port=ssh" and NOT my new port. Fail2ban was banning that IP on the standard ssh port of 22 and NOT my new port I selected in my sshd.conf file.

What is crazy is that I have had about 6 beers at a family party and I just got home to work on it and I figured it out... Guess I need to do that more often when I work on my server.



Thanks guys for your suggestions!

Crossposting threads is a violation of the LQ rules (rule #7) you agreed to adhere to when you signed up.
No exceptions.

LQ expects you to either refrain from doing that or ask a moderator to move your thread to a more appropriate forum.
Waiting 24 hours before doing something seems reasonable.

Let me know if you disagree with or don't understand the reasoning behind this all.

I agree with you. Cross posting can be problematic. I was thinking I waited a day before I posted again in the Slack Forums. But the time stamp from my first post to my second post shows only 40 minutes which seems strange. I could have swore I gave it a full day... If not, then that was my fault.

NP, you're aware now how it should be done and that's what matters most, right? Have fun!