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

[Brian Callahan]

<snip my original thread for readability>

On 12/12/2013 12:51 AM, nanotek wrote:
>
>>>
>>> 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

That is not the latest Tor. Perhaps you should look into 0.2.4.18-rc 
(which is available under security/tor-devel). It's much better, really.

> 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.
>