RE: [mod-security-users] Getting first SecSelectiveFilter to work

[<Ral...@it...>]

>=20
>   BTW, let's go back to the users' list when we're discussing
>   ModSecurity.
>=20
>=20

Sorry for the detour,
so back to the list.


> > Oops, I have revisited the list of *all* LOCATIONS,
> > as it claims in the doc
> > (
> >
http://www.modsecurity.org/documentation/modsecurity-apache-manua
> > l-1.9.2.html#N103CE )
> > but I didn't discover HTTP_User-Agent therein.
> > Could you please refer me to a complete list
> > since guessing what are valid Location tokens is a bit
involved.
>=20
>   It is there, look at the end of the locations list. The
"User-Agent"
>   part it the name of the header. You can put any header name
there.


Sorry Ivan, but I still couldn't find it in the Location list.
Actually, the string agent only appears three times in the whole
of the single html
version of the doc.
And the first time it appears is in an audit log excerpt where
the actual HTTP Request
Header is cited.

http://www.modsecurity.org/documentation/modsecurity-apache-manua
l-1.9.2.html#N109C4


So I guess any valid request header field as named in section 5.3
of RFC2616
http://www.faqs.org/rfcs/rfc2616.html will be accepted by
mod_security if prepended
with "HTTP_", right ?


Actually, I was fooled by lwp-request (i.e. the LWP demo script
that comes with Perl's LWP module).
Though it according to its POD recognizes an -H switch that you
can supply any HTTP request header field
I made a little quoting mistake whereby it kept its default
User-Agent setting, which naturally was
lwp-request and would never match my filter.
I realized this when I reached line 383 in lwp-request in the
debugger where the -H supplied HTTP header
is dissected and if user-agent match supplied to the user_agent()
mutator method.

This of course could more easily be seen after I changed the log
format to Combined in httpd.conf
as it included referer and agent fields.

I also removed the Perlish clutter from my filter (e.g. match
delimeters)
so that it now read

# tail -4 ../../conf.d/security.conf=20

    SecFilterSelective HTTP_User-Agent
"^(tintin|snowy)-statuscheck$" log,deny,status:404

</IfModule>


(n.b. the trailing action is redundant as it is the default
filter action defined further above)


When I now run lwp-request again I can see my filter catchning
this


# tail -18 modsec_audit.log=20

=3D=3D51661f45=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Request: 123.123.123.123 123.123.123.123 - -
[23/Feb/2006:11:58:15 +0100] "GET /server-status?auto HTTP/1.1"
40
4 211 "-" "tintin-StatusCheck" - "-"
Handler: server-status
----------------------------------------
GET /server-status?auto HTTP/1.1
Connection: close
Host: 123.123.123.123
User-Agent: tintin-StatusCheck
mod_security-action: 404
mod_security-message: Access denied with code 404. Pattern match
"^(tintin|snowy)-statuscheck$" at HEADER("User-Agent")

HTTP/1.1 404 Not Found
Content-Length: 211
Connection: close
Content-Type: text/html; charset=3Diso-8859-1
--51661f45--


Many thanks for the immediate help Ivan!



>=20
>   How many web servers are there? Make sure to check out the
>   recently-announced ModSecurity Console
>   (http://www.thinkingstone.com/products/console/) - I'm sure
>   it would make your life much easier.


> > I also would have liked to chroot the webserver.
> > But again I'm plagued with third party closed source CGI
> > programmes that I must provide
> > on customer demand.
>=20
>   Yes, that's always a problem. So you need to support various
>   CGIs in addition to Tomcat? I guess the best thing you can
>   do is use suEXEC to run the CGIs.
>=20

> > If that alone wasn't bad enough they soon will coerce me into
> > placing some JSP or Java servlets
> > on the server, and I have no Java experience whatsoever.
>=20
>   You could be able to secure Java easily, because it comes
>   with MAC facilities built in. Try reading about the Security
>   Manager.
>=20

> > But I have no idea how to secure a Tomcat, let alone mod_jk.
>=20
>   At least you can run Tomcat on a high port as a non-root
user.

I for sure would never let a server run as root proc
(Apache is an exception as it initializes as root but
forks/threads all its client accept() children under User and
Group)
And afaik the Tomcat default Port is 8080, isn't it?
(but can be set in server.xml anyway)