[Tor-BSD] New: DNS hijacking Old: Re: NYCBUG1 earns a T-shirt!

Thu Dec 12 00:51:30 EST 2013

> nanotek:
>> Brian Callahan bcallah at devio.us Mon Dec 9 00:09:44 EST 2013
>>> Hi tor-bsd --
>>>
>>> As the subject line states, I got an email tonight from the Tor
>>> project offering me a free T-shirt for my (but really: our) efforts
>>> in maintaining a Tor node.
>>>
>>> The Tor project states that they have observed NYCBUG1 running for
>>> 61 days with an average bandwidth of 1170 KB/s. This is more than
>>> double the minimum bandwidth of 500 KB/s to be eligible for a
>>> shirt.
>>>
>>> It is nice to get recognition for running a stable Tor node for
>>> any length of time, but we can do better!
>>>
>>> We need more people running *BSD-based Tor nodes. And not just
>>> running them but being vocal about it as well. This list, I hope in
>>> time, will be teeming with discussion about Tor on *BSD. Not only
>>> will it help us as a collective with solving each others' issues
>>> and as a tip/hint repository - it will also allow us to come
>>> forward to the Tor developers as a large group who must be heard.
>>> And it benefits the Tor project by dissipating the current
>>> monoculture. Care about Tor? Then start running your own *BSD-based
>>> Tor node. And take part in this mailing list!
>>>
>>> Btw, NYCBUG1 was updated about two weeks ago to 0.2.4.18-rc and
>>> everything is going well.
>>>
>>> As always, NYCBUG1 details can be found here:
>>> https://atlas.torproject.org/#details/C8DE1C4F154417DF35142ECF4C8EB454D020E118
>>>
>>>
>>>
>>>
> ~Brian
>>
>> Congrats!
>>
>> Maybe my dilemma can be solved with the help of this list, and
>> generate some discussion in the process. I'm trying to establish an
>> exit relay on my FreeBSD box but am facing some problems. I haven't
>> attempted fixing this in over a week because I came to the conclusion
>> that my ISP is hijacking my DNS requests (which would be a very
>> recent development as I was running a relay on my Win7 box with no
>> problems not too long ago), and that is rendering my relay
>> inaccessible. You all would have a better understanding than me
>> though.
>
> I had this a long while ago with various relays and bridges.. "DNS
> hijacking" IIRC, is really not a deterrent to running a relay.  It just
> means that if you attempt to hit a non-existent domain, your DNS is
> redirecting you to a search page.
>
> The best bet is just to use other public DNS, and not your providers.
>

I'd never heard of it till noticing those tor log entries. I thought it
might be affecting my relay because I never had any problems prior to
those strange entries appearing. Although, my relay was running as a
bridge before.

>>
>> Some intel to work with:
>>
>> ## torrc SocksPort 0 Log notice file
>> /usr/local/var/log/tor/notices.log RunAsDaemon 1 ORPort 9001 Nickname
>> alphadet RelayBandwidthRate 256 KB RelayBandwidthBurst 512 KB
>> AccountingMax 20 GB AccountingStart month 3 15:00 ContactInfo mark
>> 696872F91EF8745B4FDF99061CB0654ACD57BC18 <mark at bsdbox.co
>> <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays>>
>
> Hmmm... why would you use this list's mailman interface in your contact
> info?

I don't know why that's there, it's not in my contact in torrc. I think
it's because I copy/pasted some of the data from a tor-relay list email
sent.

>
>> DirPort 9030 ExitPolicy accept *:6660-6667,reject *:*
>>
>> ## relevent excerpts from notices.log Dec 03 03:12:40.000 [notice]
>> Reloaded microdescriptor cache.  Found 0 descriptors. [...] Dec 03
>> 03:12:41.000 [notice] Heartbeat: It seems like we are not in the
>> cached consensus. Dec 03 03:12:41.000 [notice] Heartbeat: Tor's
>> uptime is 0:00 hours, with 3 circuits open. I've sent 0 kB and
>> received 0 kB. [...] Dec 03 03:12:51.000 [notice] We'd like to launch
>> a circuit to handle a connection, but we already have 32
>> general-purpose client circuits pending. Waiting until some finish.
>> [...] Dec 03 03:13:33.000 [notice] We now have enough directory
>> information to build circuits. [...] Dec 03 03:13:34.000 [notice]
>> Bootstrapped 90%: Establishing a Tor circuit. Dec 03 03:13:38.000
>> [notice] Tor has successfully opened a circuit. Looks like client
>> functionality is working. Dec 03 03:13:38.000 [notice] Tor has
>> successfully opened a circuit. Looks like client functionality is
>> working. Dec 03 03:13:38.000 [notice] Bootstrapped 100%: Done. Dec 03
>> 03:13:38.000 [notice] Bootstrapped 100%: Done. Dec 03 03:13:38.000
>> [notice] Now checking whether ORPort 110.146.133.98:9001 and DirPort
>> 110.146.133.98:9030 are reachable... (this may take up to 20 minutes
>> -- look for log messages indicating success) Dec 03 03:13:38.000
>> [notice] Now checking whether ORPort 110.146.133.98:9001 and DirPort
>> 110.146.133.98:9030 are reachable... (this may take up to 20 minutes
>> -- look for log messages indicating success) Dec 03 03:13:41.000
>> [notice] Self-testing indicates your ORPort is reachable from the
>> outside. Excellent. Publishing server descriptor. Dec 03 03:13:46.000
>> [notice] Self-testing indicates your DirPort is reachable from the
>> outside. Excellent.
>>
>> ## tor process PID USERNAME    THR PRI NICE   SIZE    RES STATE
>> TIME   WCPU COMMAND 54844 _tor          2  20    0 65536K 45648K
>> sbwait   0:16  0.00% tor
>>
>> This all would indicate Tor is successfully running as a relay.
>> Atlas, however, still reports differently:
>> https://atlas.torproject.org/#details/EE16D7A4FBCF6494FEE75C856D76782295CB9DC4
>>
>>
>
> nothing showed up, as you noted.  I wasnt able to connect to it either.
>
>>
>>
>> However, the following reveals, what I believe is, the problem:
>>
>> ## more notices.log excerpts Dec 02 15:37:54.000 [warn] Mismatched
>> accounting interval: moved by -87.92%. Starting a fresh one. Dec 03
>> 03:12:38.000 [notice] No AES engine found; using AES_* functions. Dec
>> 03 03:12:38.000 [notice] This version of OpenSSL has a slow
>> implementation of counter mode; not using it. Dec 03 03:12:40.000
>> [notice] We weren't able to find support for all of the TLS
>> ciphersuites that we wanted to advertise. This won't hurt security,
>> but it might make your Tor (if run as a client) more easy for censors
>> to block. Dec 03 03:13:44.000 [notice] Your DNS provider gave an
>> answer for "hxfu4dgtdhch", which is not supposed to exist. Apparently
>> they are hijacking DNS failures. Trying to correct for this. We've
>> noticed 1 possibly bad address so far.
>>
>
> I would start troubleshooting by turning accounting off.  Are you on a
> metered connection?

Yes, 500 GB. I will turn it off though.

>
>>
>>
>> What is hard to decipher, is that (a) the relay worked for brief
>> moments (data can be found on both metrics. and
>> atlas.torproject.org), and (b) the tor log explicitly states that the
>> relay is reachable.
>>
>> I'd love to get a relay going on this box, if you have any ideas I
>> am more than willing to implement them. Thanks!
>
> What tor version is it?
>
> Is there anything else happening in the log file after the dns?
>
>
> When it's up at least, can you run tcpdump on the interface to see?
>
> Maybe something like:
>
> $  tcpdump -e -i <interface> | grep 9001
>
> g
> _______________________________________________
> A list focused on porting and running Tor software on *BSD Unix
> Tor-BSD mailing list
> Tor-BSD at nycbug.org
> http://www.nycbug.org/mailman/listinfo/tor-bsd
>

Latest Tor compiled from ports (tor 0.2.3.25) with default build
configuration options. Regarding the log file, nothing of note: just
either the "[notice] Self-testing indicates your ORPort is reachable
from the outside. Excellent. Publishing server descriptor", or, more
often, the opposite notice warning that it isn't reachable. Regardless
of what the test returns, my relay never appears online according to
atlas or metrics.

I'm going to play with it today, see if I can get anywhere. I'll try
what you've suggested and try gather some more intelligence.

It may be worth noting this is running in a jail, though, after these
problems, I tried running it on the host system and encountered the same
troubles. In fact, I even fired it back up on my Win box and had the
same result. Ports 9001, 9030, and 6660-6667 are open on my router. I
tried with PF both on and off. What rdr rule would be necessary, if any?
I can share my pf.conf if you like, but considering I had the same
problems with it both on and off, I can only imagine I might be missing
a rdr rule. Though, both Apache and Postfix are running fine in their
own jails with no specific redirect. Thanks, George.

-- 
nanotek at bsdbox.co