Nice!&nbsp; 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&nbsp; input&nbsp; before processing it.&nbsp; 
<br><br><br><div><span class="gmail_quote">On 8/11/07, <b class="gmail_sendername">Mike Cardwell</b> &lt;<a href="mailto:tor@lists.grepular.com">tor@lists.grepular.com</a>&gt; 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&#39;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>&lt;Location /tor/&gt;<br>&nbsp;&nbsp; SecRuleEngine&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; On<br>&nbsp;&nbsp; SecRequestBodyAccess&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;On<br>&nbsp;&nbsp; SecResponseBodyAccess&nbsp;&nbsp;&nbsp;&nbsp; Off<br>&nbsp;&nbsp; SecRuleInheritance&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Off<br>&nbsp;&nbsp; SecAuditLogRelevantStatus &quot;^500$&quot;
<br>&nbsp;&nbsp; SecDefaultAction&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;log,auditlog,deny,phase:2,status:500,severity:&#39;2&#39;&quot;<br><br>&nbsp;&nbsp; SecRule HTTP_HOST&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;!^\d{1,3}(?&gt;\.\d{1,3}){3}$&quot; &quot;msg:&#39;Host header must be IP address&#39;&quot;
<br>&nbsp;&nbsp; SecRule REQUEST_PROTOCOL &quot;!^HTTP/1\.[01]$&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;msg:&#39;HTTP/1.0 or HTTP/1.1 only&#39;&quot;<br>&nbsp;&nbsp; SecRule REQUEST_METHOD&nbsp;&nbsp; &quot;!^GET$&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;msg:&#39;We only allow GETs here&#39;&quot;
<br>&nbsp;&nbsp; SecRule REQUEST_HEADERS:Content-Length &quot;!^0?$&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;msg:&#39;No request message bodies allowed&#39;&quot;<br><br>&nbsp;&nbsp; SecRule REQUEST_URI &quot;!^/tor/server/authority$&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;chain,msg:&#39;Badly formed uri&#39;&quot;
<br>&nbsp;&nbsp; SecRule REQUEST_URI &quot;!^/tor/status/all$&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;chain&quot;<br>&nbsp;&nbsp; SecRule REQUEST_URI &quot;!^/tor/running-routers$&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;chain&quot;
<br>&nbsp;&nbsp; SecRule REQUEST_URI &quot;!^/tor/dir\.z$&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;chain&quot;<br>&nbsp;&nbsp; SecRule REQUEST_URI &quot;!^/tor/server/(?&gt;d|fp)/(?&gt;[A-F0-9]{40})(?&gt;\+[A-F0-9]{40})*\.z$&quot; &quot;chain&quot;
<br>&nbsp;&nbsp; SecRule REQUEST_URI &quot;!^/tor/status/fp/[A-F0-9]{40}(?&gt;\+[A-F0-9]{40})*\.z$&quot;<br><br>&nbsp;&nbsp; ProxyPass <a href="http://127.0.0.1:9030/tor/">http://127.0.0.1:9030/tor/</a><br>&lt;/Location&gt;<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 &quot;ProxyPassReverse&quot; entry in the faq seems redundant as the tor<br>directory http service doesn&#39;t appear to ever return a redirect response.
<br><br>Mike<br></blockquote></div><br>