Re: [tor-relays] HOW-TO: Simple DNS resolver for tor exit operators
My idea is designed to protect the exit node against a DNS attack from the owner of the DNS server. Not from the ISP or an attacker monitoring the traffic going in and out of the ISP data center. On 12/09/2017 19:38, Ralph Seichter wrote:
On 12.09.17 21:17, jpmvtd261@laposte.net wrote:
My idea is to make more DNS queries than necessary, in order to hide the useful DNS queries among useless DNS queries.
I'm not sure what you are trying to accomplish. Usually, a DNS query is followed by an outbound connection to the returned IP address. Your ISP can always monitor these connections from your exit node, no matter what additional "query noise" you might introduce.
This is not fiction. One of my ISPs sends me automated tickets every once in a while, about network scans that abuse my exit nodes. Not only are connections recorded, they are analysed for patterns.
-Ralph
On 12.09.17 22:11, jpmvtd261@laposte.net wrote:
My idea is designed to protect the exit node against a DNS attack from the owner of the DNS server. Not from the ISP or an attacker monitoring the traffic going in and out of the ISP data center.
I'm not certain what you consider a "DNS attack". Many exit node operators run a caching DNS resolver on their exits, which is easily done. Lacking that, you can use the resolvers run by your ISP, who can monitor all outbound traffic anyway, as I mentioned. -Ralph
I wonder if these are all half-measures, and Tor needs a first-class solution to the DNS weakness. Every Tor relay can have a simple resolver built-in, and/or perhaps all Tor relays could be running a DHT-style global DNS cache. In case of a cache miss, the exit relay could build a circuit to another relay and ask it to query core DNS servers on its behalf. Alternatively, the Tor community could run our own DNS servers, and every exit node would use those by default. ...I have seen some papers discussing DNS-assisted traffic correlation attacks, but I still don't know how serious that threat is. I am basically not sure if DNS is a high-priority vulnerability right now, or just a distraction. -----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of Ralph Seichter Sent: Tuesday, September 12, 2017 1:25 PM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] HOW-TO: Simple DNS resolver for tor exit operators On 12.09.17 22:11, jpmvtd261@laposte.net wrote:
My idea is designed to protect the exit node against a DNS attack from the owner of the DNS server. Not from the ISP or an attacker monitoring the traffic going in and out of the ISP data center.
I'm not certain what you consider a "DNS attack". Many exit node operators run a caching DNS resolver on their exits, which is easily done. Lacking that, you can use the resolvers run by your ISP, who can monitor all outbound traffic anyway, as I mentioned. -Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 12.09.17 22:43, Igor Mitrofanov wrote:
Every Tor relay can have a simple resolver built-in, and/or perhaps all Tor relays could be running a DHT-style global DNS cache.
"Simple resolver" won't do, IMO. It must be robust and fully DNSSEC capable, which means reinventing the wheel. There is enough good DNS resolver software available. Why invest time and effort in writing yet another resolver, when the developer resources can be spent on Tor's core functionality instead? I don't like the idea of feature creep.
I am basically not sure if DNS is a high-priority vulnerability right now, or just a distraction.
That's what I am asking myself as well. -Ralph
My idea is designed to protect the exit node against a DNS attack from the owner of the DNS server. Not from the ISP or an attacker monitoring the traffic going in and out of the ISP data center.
So in this threat model you trust your ISP but not your DNS provider? Why not just use the ISP's DNS then? Combine it with a local caching resolver and call it a day. I don't really see a compelling use-case for just inserting DNS noise and not following up with IP noise. I'm interested in things like Google's DNS-over-HTTPS implementation: https://developers.google.com/speed/public-dns/docs/dns-over-https. It encrypts DNS traffic on the wire. There are already some fairly good client-side implementations. However, we need other providers to put up DNS-over-HTTPS endpoints, since no one wants to trust Google.
On Tue, 12 Sep 2017 13:43:35 -0700 "Igor Mitrofanov" <igor.n.mitrofanov@gmail.com> wrote:
Alternatively, the Tor community could run our own DNS servers, and every exit node would use those by default.
On Tue, 12 Sep 2017 22:11:23 +0200 (CEST) jpmvtd261@laposte.net wrote:
from the owner of the DNS server.
THE owner of THE dns server. Right. Too bad DNS servers are not something a regular person can own, so we have to be at mercy of those shady all-knowing uber-powerful Owners of the DNS Servers. Lacking that, there must be a Community which gathers together to Run One. Oh wait, we need none of that, and running a resolver which answers to no one and can only be tracked via traffic monitoring (i.e. if they do that, you're f*cked anyway) is just an "apt-get install unbound" away. Are you sure you understand how Internet architecture works, before proposing "solutions". -- With respect, Roman
On 12.09.17 23:06, Roman Mamedov wrote:
Too bad DNS servers are not something a regular person can own, so we have to be at mercy of those shady all-knowing uber-powerful Owners of the DNS Servers.
I take it you're being ironic? These days, if you want to get serious about controlling your own domains and not relying on other people's server infrastructure, all it takes to run a pair of nameservers (that's the minimum due to IP address range constraints) is the raw knowledge how to do it and about $10, or local currency equivalent, for two virtual servers. DNSSEC, key-based server synchronisation, the works. One might say that the more people run their own nameservers, the harder it gets for attackers to gather data or interfere with the DNS system. -Ralph
On Tue, 12 Sep 2017 23:28:35 +0200 Ralph Seichter <m16+tor@monksofcool.net> wrote:
On 12.09.17 23:06, Roman Mamedov wrote:
Too bad DNS servers are not something a regular person can own, so we have to be at mercy of those shady all-knowing uber-powerful Owners of the DNS Servers.
I take it you're being ironic?
Guess I failed at doing that well, if you had to clarify. (Or maybe you didn't read my entire message.)
One might say that the more people run their own nameservers, the harder it gets for attackers to gather data or interfere with the DNS system.
Running your own authoritative nameservers is laudable as well, but the current discussion is about recursive resolvers. You know, the likes of 8.8.8.8 and the ones your ISP runs for their clients "to reduce traffic". Point is that it is entirely possible, and really easy, to just have your own instance of that. It will not use any fixed "upstream server" other than the root nameservers (and those, only to ask generic depersonalized stuff such as "who handles the .com zone"). Note that 'dnsmasq' won't do, that's just a caching proxy to a fixed set of a few upstream DNS resolvers; you need 'unbound' which IS a full independent DNS resolver itself. (Unbound is caching as well, though). -- With respect, Roman
On 12.09.17 23:43, Roman Mamedov wrote:
I take it you're being ironic?
Guess I failed at doing that well, if you had to clarify. (Or maybe you didn't read my entire message.)
I did read it. Just the pitfalls of non-verbal communication, and I'm also not a native English speaker. ;-)
Running your own authoritative nameservers is laudable as well, but the current discussion is about recursive resolvers. You know, the likes of 8.8.8.8 and the ones your ISP runs for their clients "to reduce traffic".
If you read *my* messages in this thread, you'll find that I am fully aware of this. I even mentioned Google's infamous resolver by IP. :-) I came across one ISP so far which does not provide resolvers for their customers but points resolv.conf to Google's servers. Not good.
Note that 'dnsmasq' won't do, that's just a caching proxy to a fixed set of a few upstream DNS resolvers; you need 'unbound' which IS a full independent DNS resolver itself.
Yeah, I use Unbound and BIND myself, with the former of course being much more frugal in terms of resource requirements. Easy to set up, too. -Ralph
Ralph Seichter <m16+tor@monksofcool.net> wrote:
On 12.09.17 23:43, Roman Mamedov wrote:
I take it you're being ironic?
Guess I failed at doing that well, if you had to clarify. (Or maybe you didn't read my entire message.)
I did read it. Just the pitfalls of non-verbal communication, and I'm also not a native English speaker. ;-)
Running your own authoritative nameservers is laudable as well, but the current discussion is about recursive resolvers. You know, the likes of 8.8.8.8 and the ones your ISP runs for their clients "to reduce traffic".
If you read *my* messages in this thread, you'll find that I am fully aware of this. I even mentioned Google's infamous resolver by IP. :-) I came across one ISP so far which does not provide resolvers for their customers but points resolv.conf to Google's servers. Not good.
Note that 'dnsmasq' won't do, that's just a caching proxy to a fixed set of a few upstream DNS resolvers; you need 'unbound' which IS a full independent DNS resolver itself.
Yeah, I use Unbound and BIND myself, with the former of course being much more frugal in terms of resource requirements. Easy to set up, too.
I'd like to add a note here for FreeBSD users. In addition to unbound or any of the other resolvers available in the ports tree, DNS queries for name-to-address resolution can be further reduced by a small caching utility that is in the base system, called nscd(8). Check the man pages for nscd.conf(5) and nsswitch.conf(5) to see how easily you can configure its use. nscd can also cache other, non-DNS queries' results as well (e.g., NIS). After setting up nsswitch.conf and nscd.conf (just a few lines each), remember to add a line that says, "nscd_enable=YES", to /etc/rc.conf and then (as root) give the following command. # service nscd start Note that the rc.conf entry will take care of starting nscd(8) after a reboot. The command shown above is only necessary when starting nscd at other times. nscd's caching service gets inserted between the resolver(3) and its queries of local DNS caches or distant name servers, and it is quite fast, but it serves only the machine it runs on. Further, it maintains per-user caches for each type of data. Any user can flush his cache of one type of data or all types of data. root also has the option of flushing all of the per-user caches by type of data or all types of data. Here is an example of an nscd configuration (nscd.conf). threads 4 enable-cache passwd yes # enable-cache group yes enable-cache hosts yes enable-cache services yes enable-cache protocols yes enable-cache rpc yes enable-cache networks yes suggested-size hosts 2111 keep-hot-count hosts 4096 positive-policy hosts lfu suggested-size services 1123 And here is nsswitch.conf to go with the above. group: files group_compat: nis hosts: cache files dns networks: cache files passwd: cache files passwd_compat: nis shells: cache files services: compat services_compat: nis protocols: cache files rpc: cache files Note that the only lines in each that pertain to the current discussion are the lines that refer to hosts. The rest are for caches of other data. As you can see, configuring this high-speed, local-service-only caching daemon is trivially easy and brief and requires installation of *no* other software. It can be used with or without a caching name server or other caching resolver software. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
If it's important enough to do on a single relay, it's important enough to do it across the entire network. I bet there are, and will always be, plenty of exit node operators not reading this email list, or not planning to do anything, or not configuring everything properly, etc. On Tue, Sep 12, 2017 at 5:25 PM, Scott Bennett <bennett@sdf.org> wrote:
Ralph Seichter <m16+tor@monksofcool.net> wrote:
On 12.09.17 23:43, Roman Mamedov wrote:
I take it you're being ironic?
Guess I failed at doing that well, if you had to clarify. (Or maybe you didn't read my entire message.)
I did read it. Just the pitfalls of non-verbal communication, and I'm also not a native English speaker. ;-)
Running your own authoritative nameservers is laudable as well, but the current discussion is about recursive resolvers. You know, the likes of 8.8.8.8 and the ones your ISP runs for their clients "to reduce traffic".
If you read *my* messages in this thread, you'll find that I am fully aware of this. I even mentioned Google's infamous resolver by IP. :-) I came across one ISP so far which does not provide resolvers for their customers but points resolv.conf to Google's servers. Not good.
Note that 'dnsmasq' won't do, that's just a caching proxy to a fixed set of a few upstream DNS resolvers; you need 'unbound' which IS a full independent DNS resolver itself.
Yeah, I use Unbound and BIND myself, with the former of course being much more frugal in terms of resource requirements. Easy to set up, too.
I'd like to add a note here for FreeBSD users. In addition to unbound or any of the other resolvers available in the ports tree, DNS queries for name-to-address resolution can be further reduced by a small caching utility that is in the base system, called nscd(8). Check the man pages for nscd.conf(5) and nsswitch.conf(5) to see how easily you can configure its use. nscd can also cache other, non-DNS queries' results as well (e.g., NIS). After setting up nsswitch.conf and nscd.conf (just a few lines each), remember to add a line that says, "nscd_enable=YES", to /etc/rc.conf and then (as root) give the following command.
# service nscd start
Note that the rc.conf entry will take care of starting nscd(8) after a reboot. The command shown above is only necessary when starting nscd at other times. nscd's caching service gets inserted between the resolver(3) and its queries of local DNS caches or distant name servers, and it is quite fast, but it serves only the machine it runs on. Further, it maintains per-user caches for each type of data. Any user can flush his cache of one type of data or all types of data. root also has the option of flushing all of the per-user caches by type of data or all types of data. Here is an example of an nscd configuration (nscd.conf).
threads 4 enable-cache passwd yes # enable-cache group yes enable-cache hosts yes enable-cache services yes enable-cache protocols yes enable-cache rpc yes enable-cache networks yes suggested-size hosts 2111 keep-hot-count hosts 4096 positive-policy hosts lfu suggested-size services 1123
And here is nsswitch.conf to go with the above.
group: files group_compat: nis hosts: cache files dns networks: cache files passwd: cache files passwd_compat: nis shells: cache files services: compat services_compat: nis protocols: cache files rpc: cache files
Note that the only lines in each that pertain to the current discussion are the lines that refer to hosts. The rest are for caches of other data. As you can see, configuring this high-speed, local-service-only caching daemon is trivially easy and brief and requires installation of *no* other software. It can be used with or without a caching name server or other caching resolver software.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Igor Mitrofanov <igor.n.mitrofanov@gmail.com> wrote:
If it's important enough to do on a single relay, it's important enough to do it across the entire network. I bet there are, and will always be, plenty of exit node operators not reading this email list, or not planning to do anything, or not configuring everything properly, etc.
I was not presenting an argument for or against anything. I was merely pointing out to other FreeBSD users that a basic and generalized caching tool existed in the base system and was very easy to use. Obviously, that piece of information is irrelevant to anyone on another OS, but FreeBSD systems have it already installed, and many of their operators are likely to be unaware of it. I was running FreeBSD for four or five years before I stumbled across it myself. The system works just fine without it, but putting it into use has the potential to speed up various system functions, name-to-address resolution being one of those. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
participants (6)
-
Igor Mitrofanov -
jpmvtd261＠laposte.net -
Ralph Seichter -
Roman Mamedov -
Scott Bennett -
tor