On Fri, 2010-04-09 at 17:44 +0200, Dominick Grift wrote:
On Fri, Apr 09, 2010 at 04:26:05PM +0100, Arthur Dent wrote:
On Fri, 2010-04-09 at 17:10 +0200, Dominick Grift wrote:
On Fri, Apr 09, 2010 at 03:23:34PM +0100, Arthur Dent wrote:
Hi Dominick,
[snip]
Does that make sense?
Yes. I guess i would confine /usr/local/bin/banip2.sh and set up a transition from httpd_t to a new banip2_t domain
Basically pretty much similar to what we did with mlogc
It would be a good exercise if you would try that. Basically follow the steps described in previous messages. only this time you do not have to create a new myapache module you can just extend the existing with interface calls to your new banip2 module.
I just thought I would give a quick update on this...
I was quite up for the challenge of writing my own policy for this, but realised that I had to get the script working properly first. Although the script worked fine when executed from the command line, it did not when run in the normal environment. I realised that the fail2ban-client app called from within the script needs to run as root. After much messing around, trying (and failing) with sudo and su- commands, editing sudoers and much other wasted effort I was stuck. Then, in a rare (for me) moment of clear-thinking I realised that the way fail2ban works, and is designed to work, is by monitoring log files for new entries and then banning the IP if the entry matches a regex. So all I had to do was to get the script to write the IP into a "log file" (which it already was) together with a timestamp, and set fail2ban to monitor that log file...
Simple!
And not an AVC in sight!
So thanks for all your help.
I think I am now ready to remove the "permissive mlogc_t;" directive from mlogc.te and put the system back into Enforcing mode.
Cheers!
Mark