Nice! Thank you for that helpful information.<br>I will definitely take note of that with the next version of JanusVM.<br>Strict rules such as these are a very good idea, because it never hurts to check your input before processing it.
<br><br><br><div><span class="gmail_quote">On 8/11/07, <b class="gmail_sendername">Mike Cardwell</b> <<a href="mailto:tor@lists.grepular.com">tor@lists.grepular.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On <a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ServerForFirewalledClients">http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ServerForFirewalledClients</a><br>one of the suggested methods to get your Directory service on port 80 if Apache is
<br>in the way is to use mod_proxy.<br><br>Personally I think sticking tors directory service behind Apache so it's<br>not exposed to the wider Internet directly is a good thing anyway. The<br>shear scale of development, usage and history of Apache makes me
<br>confident that it is less likely to contain security holes than tor,<br>(see recent exploit)<br><br>This is not a dig! I am writing this email to share some ModSecurity<br>(<a href="http://www.modsecurity.org/">http://www.modsecurity.org/
</a>) rules that I have been developing and using<br>to severely restrict the requests that get forwarded onto the tor daemon by<br>mod_proxy. Someone may find them useful. Here are the relevant parts of<br>my Apache vhost:
<br><br><Location /tor/><br> SecRuleEngine On<br> SecRequestBodyAccess On<br> SecResponseBodyAccess Off<br> SecRuleInheritance Off<br> SecAuditLogRelevantStatus "^500$"
<br> SecDefaultAction "log,auditlog,deny,phase:2,status:500,severity:'2'"<br><br> SecRule HTTP_HOST "!^\d{1,3}(?>\.\d{1,3}){3}$" "msg:'Host header must be IP address'"
<br> SecRule REQUEST_PROTOCOL "!^HTTP/1\.[01]$" "msg:'HTTP/1.0 or HTTP/1.1 only'"<br> SecRule REQUEST_METHOD "!^GET$" "msg:'We only allow GETs here'"
<br> SecRule REQUEST_HEADERS:Content-Length "!^0?$" "msg:'No request message bodies allowed'"<br><br> SecRule REQUEST_URI "!^/tor/server/authority$" "chain,msg:'Badly formed uri'"
<br> SecRule REQUEST_URI "!^/tor/status/all$" "chain"<br> SecRule REQUEST_URI "!^/tor/running-routers$" "chain"
<br> SecRule REQUEST_URI "!^/tor/dir\.z$" "chain"<br> SecRule REQUEST_URI "!^/tor/server/(?>d|fp)/(?>[A-F0-9]{40})(?>\+[A-F0-9]{40})*\.z$" "chain"
<br> SecRule REQUEST_URI "!^/tor/status/fp/[A-F0-9]{40}(?>\+[A-F0-9]{40})*\.z$"<br><br> ProxyPass <a href="http://127.0.0.1:9030/tor/">http://127.0.0.1:9030/tor/</a><br></Location><br><br>I put another http service behind Apache earlier this year unrelated to
<br>tor (I wont mention the name of the product). After it had been running<br>for a couple of months, we found a DOS that could be performed<br>accidently by doing a GET request in a certain way. Whilst waiting<br>for a bug fix, because I had the flexibility of Apache in front of it,
<br>it was a synch to just stick a rewrite rule in place to prevent the<br>request taking place and the DOS happening.<br><br>P.S. The "ProxyPassReverse" entry in the faq seems redundant as the tor<br>directory http service doesn't appear to ever return a redirect response.
<br><br>Mike<br></blockquote></div><br>