ModSecurity v2 Apache rules for directory servers

[Kyle Williams]

"Actually they are horrible."

Why?

"They already are out of date and would reject proper directory requests."

OK, good to know.
Do you think better rules, or rules that don't break server requests, could
be achieved?

"Please don't do stuff like this."

Why not?  I don't see any problem in validating/checking the behavior or
request/fingerprints of incoming connections to Tor, so long as it doesn't
break Tor (hence QA testing after R&D).  Why would checking input be a bad
thing?




On 8/14/07, Peter Palfrader <peter at palfrader.org> wrote:
>
> On Tue, 14 Aug 2007, Kyle Williams wrote:
>
> >>   SecRule REQUEST_URI
> "!^/tor/server/authority$"
> "chain,msg:'Badly formed uri'"
> >>   SecRule REQUEST_URI
> "!^/tor/status/all$"                                             "chain"
> >>   SecRule REQUEST_URI
> "!^/tor/running-routers$"                                        "chain"
> >>   SecRule REQUEST_URI
> "!^/tor/dir\.z$"                                                 "chain"
> >>   SecRule REQUEST_URI
> "!^/tor/server/(?>d|fp)/(?>[A-F0-9]{40})(?>\+[A-F0-9]{40})*\.z$" "chain"
> >>   SecRule REQUEST_URI
> "!^/tor/status/fp/[A-F0-9]{40}(?>\+[A-F0-9]{40})*\.z$"
>
> > Nice!  Thank you for that helpful information.
> > I will definitely take note of that with the next version of JanusVM.
> > Strict rules such as these are a very good idea, because it never hurts
> to
> > check your  input  before processing it.
>
> Actually they are horrible.  They already are out of date and would
>
reject proper directory requests.  Please don't do stuff like this.
>
> --
>                            |  .''`.  ** Debian GNU/Linux **
>       Peter Palfrader      | : :' :      The  universal
> http://www.palfrader.org/ | `. `'      Operating System
>                            |   `-    http://www.debian.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20070814/189f8ad3/attachment.htm>