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@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/selinux
Attachment:
pgpci8HwR3k1y.pgp
Description: PGP signature
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
