ModSecurity v2 Apache rules for directory servers

Kyle Williams kyle.kwilliams at gmail.com
Tue Aug 14 08:10:12 UTC 2007


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.


On 8/11/07, Mike Cardwell <tor at lists.grepular.com> wrote:
>
> On
> http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ServerForFirewalledClients
> one of the suggested methods to get your Directory service on port 80 if
> Apache is
> in the way is to use mod_proxy.
>
> Personally I think sticking tors directory service behind Apache so it's
> not exposed to the wider Internet directly is a good thing anyway. The
> shear scale of development, usage and history of Apache makes me
> confident that it is less likely to contain security holes than tor,
> (see recent exploit)
>
> This is not a dig! I am writing this email to share some ModSecurity
> (http://www.modsecurity.org/) rules that I have been developing and using
> to severely restrict the requests that get forwarded onto the tor daemon
> by
> mod_proxy. Someone may find them useful. Here are the relevant parts of
> my Apache vhost:
>
> <Location /tor/>
>    SecRuleEngine             On
>    SecRequestBodyAccess      On
>    SecResponseBodyAccess     Off
>    SecRuleInheritance        Off
>    SecAuditLogRelevantStatus "^500$"
>
> SecDefaultAction          "log,auditlog,deny,phase:2,status:500,severity:'2'"
>
>    SecRule HTTP_HOST        "!^\d{1,3}(?>\.\d{1,3}){3}$" "msg:'Host header
> must be IP address'"
>    SecRule REQUEST_PROTOCOL "!^HTTP/1\.[01]$"            "msg:'HTTP/1.0 or
> HTTP/1.1 only'"
>    SecRule REQUEST_METHOD   "!^GET$"                     "msg:'We only
> allow GETs here'"
>    SecRule REQUEST_HEADERS:Content-Length "!^0?$"        "msg:'No request
> message bodies allowed'"
>
>    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$"
>
>    ProxyPass http://127.0.0.1:9030/tor/
> </Location>
>
> I put another http service behind Apache earlier this year unrelated to
> tor (I wont mention the name of the product). After it had been running
> for a couple of months, we found a DOS that could be performed
> accidently by doing a GET request in a certain way. Whilst waiting
> for a bug fix, because I had the flexibility of Apache in front of it,
> it was a synch to just stick a rewrite rule in place to prevent the
> request taking place and the DOS happening.
>
> P.S. The "ProxyPassReverse" entry in the faq seems redundant as the tor
> directory http service doesn't appear to ever return a redirect response.
>
> Mike
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20070814/20980ea5/attachment.htm>


More information about the tor-talk mailing list