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,
> >
> > I'm sorry to bother you again, but everything seems to be going just
> > fine since the last lot of policy updates, so I decided to move into the
> > next phase of my project.
> >
> > You're going to hate me for this...
> >
> > What I have is a Mod-Sec rule that detects a particular kind of attack;
> > when detected it identifies the IP address of the attacker and (using
> > the modsec "exec" function) passes this to a script.
> >
> > During our recent exchange I was using this rule for testing, but for
> > now all the script does is write the IP address into a file. (This
> > worked by the way).
> >
> > Now for the next part. Instead of writing it to a file I want to ban the
> > IP in iptables using a feature of the fail2ban application which I also
> > have running on this machine.
> >
> > The script uses the following command:
> > fail2ban-client set modsec banip $IP
> > touch -c /var/log/httpd/modsec_audit.log
> >
> > where $IP is the IP address passes from mod-sec, the "banip" is a
> > argument of the fail2ban-client app which initiates a manual banning of
> > the IP and "modsec" is the name of the "jail" (in fail2ban
parlance) to
> > be activated for this IP.
> >
> > The "touch" command is necessary to trick fail2ban into thinking
that
> > the log file it is monitoring has been updated and thus needs to wake
> > itself and take action.
> >
> > Putting all this together now gives me this (single) avc when testing:
> >
> > Raw Audit Messages :
> >
> > node=troodos.org.uk type=AVC msg=audit(1270821681.36:50303): avc: denied {
search } for pid=30224 comm="fail2ban-client" name="fail2ban" dev=sda5
ino=476186 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
> > node=troodos.org.uk type=SYSCALL msg=audit(1270821681.36:50303): arch=40000003
syscall=102 success=no exit=-13 a0=3 a1=bfa9b0e0 a2=b6810c a3=b76fb2c8 items=0 ppid=30222
pid=30224 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48
tty=(none) ses=4294967295 comm="fail2ban-client" exe="/usr/bin/python"
subj=unconfined_u:system_r:httpd_t:s0 key=(null)
> >
> > How best to handle this?
>
> I am not sure if i understand how that goes. From the avc denials above i can tell
that fail2ban-client runs in the httpd_t domain. That means mlogc is not running it but
some process in the httpd_t domain.
>
> What runs the script?
I guess it must be mod-security itself.
I have a rule in modsec as follows:
SecRule REQUEST_URI_RAW "(?:wantsfly|w00tw00t)"
"phase:1,t:lowercase,deny,log,status:403, setenv:REMOTEIP=%{REMOTE_ADDR},
exec:/usr/local/bin/banip2.sh"
This means that if someone tries to probe my webserver with a typical
signature (in this case "wantsfly") Mod-Security will execute the
script /usr/local/bin/banip2.sh within which "fail2ban-client" is called
to block the IP address in iptables.
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.
Thanks
Mark
--
selinux mailing list
selinux(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux