On Dec 19, 2007 12:46 AM, Scott Bennett <<a href="mailto:bennett@cs.niu.edu">bennett@cs.niu.edu</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A little while ago, I added another filter rule to the router here to<br>stop an apparently endless, rapid-fire series of directory requests hitting<br>my tor server's DirPort from <a href="http://125.35.9.66" target="_blank">
125.35.9.66</a>, which appears to be in China. The<br>last time I reported this type of thing, you may recall, it came from a site<br>in Italy. The symptom, like the last time, was that output rate on my<br>machine's main Ethernet interface was running steadily around the transmit
<br>rate limit imposed by my ADSL line. dig(1) shows:<br><br>; <<>> DiG 9.3.4-P1 <<>> -x <a href="http://125.35.9.66" target="_blank">125.35.9.66</a> any<br>;; global options: printcmd<br>;; Got answer:
<br>;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 63929<br>;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0<br><br>;; QUESTION SECTION:<br>;66.9.35.125.in-addr.arpa. IN ANY
<br><br>;; AUTHORITY SECTION:<br>9.35.125.in-addr.arpa. 10800 IN SOA <a href="http://ns.bta.net.cn" target="_blank">ns.bta.net.cn</a>. <a href="http://root.ns.bta.net.cn" target="_blank">root.ns.bta.net.cn</a>
. 2006020501 28899 7200 604800 86400<br><br>;; Query time: 351 msec<br>;; SERVER: 66.225.32.4#53(<a href="http://66.225.32.4" target="_blank">66.225.32.4</a>)<br>;; WHEN: Wed Dec 19 02:40:29 2007<br>;; MSG SIZE rcvd: 96<br>
<br> Is anyone else having this kind of trouble, regardless of the apparent<br>origin(s) of the attack(s)? I don't mind legitimate requests for directory<br>service tying up all or nearly all of my available output bandwidth, but I
<br>do object to morons conducting a DoS attack to keep others from getting<br>directory service from my tor servers directory mirror. If others are also<br>finding their tor servers being hit like this, then perhaps we need to think
<br>up an automated way to deny directory service to abusers in order to put a<br>stop to such activity.<br><br><br> Scott Bennett, Comm. ASMELG, CFIAG<br>**********************************************************************
<br>* Internet: bennett at <a href="http://cs.niu.edu" target="_blank">cs.niu.edu</a> *<br>*--------------------------------------------------------------------*<br>* "A well regulated and disciplined militia, is at all times a good *
<br>* objection to the introduction of that bane of all free governments *<br>* -- a standing army." *<br>* -- Gov. John Hancock, New York Journal, 28 January 1790 *
<br>**********************************************************************<br></blockquote></div><br><br>This is just a theory, no hard facts to back it up.<br>
When I'm messing around with Tor's ControlPort, I've noticed that my
Tor traffic just hangs until whatever I'm doing on the ControlPort
stops. There have been a couple of times where I do something very
wrong on the controlport and Tor just "freezes" (does not route any
traffic) until I close my connection with the ControlPort. I'm wondering if the same is true for when someone is fetching descriptors from the DirPort?<br><br>
Does Tor traffic "freeze" (not route traffic) until the Dirport completes its task?<br>
<br>Next guess...<br>
If someone where to be attacking, oh say, a hidden service, and your
node was the Introduction Point for that hidden service, then perhaps
someone is trying to force the owner of the hidden service to choose a
new introduction point.<br>
<br>
What is the uptime of your node? <br>
Have you typically been running it for a long time?<br>
If someone is DoSing your Dirport, why not just turn it off?<br>
<br>
BTW, the SOA for your DIG request, <a href="http://ns.bta.net.cn/" target="_blank">ns.bta.net.cn</a> (<a href="http://202.96.0.133">202.96.0.133</a>), had a direct match on <a href="http://cryptome.org/nsa-ip-update13.htm">
http://cryptome.org/nsa-ip-update13.htm</a><br>
Just thought you should know...<br>
<br><br>