This my second question is a continuation of my first one.

Setup is default Kali 2 and configured anonymous user from TransparentProxy manual on it.

While I'm using nameserver in /etc/resolv.conf - everything is fine. All console network-tools like dig, nslookup, host, etc, are working normally with resolving *.onion domains into IP addresses.

But, If dhclient rewriting /etc/resolv.conf with my local DNS-servers, this idyll disappearing...

As you can read from my first question, I'm catching DNS-requests with Wireshark on lo-interface. dig to *.onion domains - redirected to lo by iptablres well, but other network-tools - not.

Why does iptables redirect works with every other domains, but does not works with *.onion and requires nameserver


My question may sounds like: Why does nameserver exists in TransparentProxy configuration, if iptables already configured to redirect every DNS-request to any IP-address to loop-back:53?

EDIT: Specially for @canonizing ironize:

$IPT -t nat -A OUTPUT ! -o lo -p tcp -m owner --uid-owner anonymous -m tcp -j REDIRECT --to-ports 9040
$IPT -t nat -A OUTPUT -p udp -m owner --uid-owner anonymous -m udp --dport 53 -j REDIRECT --to-ports 53
$IPT -t filter -A OUTPUT -p tcp -m owner --uid-owner anonymous -m tcp --dport 9040 -j ACCEPT
$IPT -t filter -A OUTPUT -p udp -m owner --uid-owner anonymous -m udp --dport 53 -j ACCEPT
$IPT -t filter -A OUTPUT ! -o lo -m owner --uid-owner anonymous -j REJECT

Anyway, I can not find difference between *.onion domains and other... And how does this difference depend on /etc/resolv.conf.

  • Are you sure your iptables rules are correct for your setup? Note that those on the wiki are explicitly marked as an example and come with a set of assumptions. – cacahuatl Sep 1 '16 at 5:23

My good advice to you - use local instance of Bind and route all DNS queries through it. I'm using it quite for a long time - no problems so far. And - dhclient will not vandalize resolv conf after this:

chattr +i /etc/resolv.conf

@canonizing ironize was right. It is my Setup. My mistake.

I've used suricata IDS in inline mode with default drop policy for almost every available rule.

So, rule number 2014939:

emerging-policy.rules:#drop udp $HOME_NET any -> any 53 (msg:"ET POLICY DNS Query
for TOR Hidden Domain .onion Accessible Via TOR"; content:"|01 00 00 01 00 00 00 
00 00 00|"; depth:10; offset:2; content:"|05|onion|00|"; fast_pattern; distance:0; 
reference:url,en.wikipedia.org/wiki/.onion; classtype:policy-violation; 
sid:2014939; rev:1;

Anyway, it is interesting, because dig's request was working:

<\331\1 \0\1\0\0\0\0\0\1\20facebookcorewwwi\5onion\0\0\1\0\1\0\0)\20\0\0\0\0\0\0\0

And host's request was not:


It is this place in rule:

content:"|01 00 00 01 00 00 00 00 00 00|"; 
fast_pattern; distance:0;

Probably, dig as a modern tool using more robust query 01000001 and it does not match old version of emerging-policy rules.

Thanx everybody. I dive. Ai ai, skipper!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.