Re: Securing DNS traffic
aa...@zadzmo.org ("Aaron B.") writes:
>This isn't really a thing where I live. The ISP's here routinely return
>A records to a scammy "search engine" instead of NXDOMAIN.
Yes, that was very popular here. But, also for legal reasons, the
providers only manipulated the answers of their own DNS resolver.
They wouldn't actively intercept DNS queries a customer sent to the
world, so running your own little resolver was sufficient to bypass
their manipulations. YMMV.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: Securing DNS traffic
So I'm not big into DNS and I don't have a firm grasp on all of these techniques, but I have an idea. This is all just a big game of who are you hiding from right? If you hide from your ISP, now you have to trust the DNS server provider. Who among them are to be trusted? For example I'm pretty sure I could set up a DNS proxy somewhere in the "cloud" on some minimal operating system, then run ipsec in transport mode between my router and that server, and point all my clients to my proxy. There, I've successfully hidden from my ISP. I could do it over IPv6 just to be extra obfuscated. But does my ISP now get interested and ask the cloud provider where my DNS traffic is going, then they ask the DNS server provider on the other end? This is all very black helicopter type of stuff but I suppose it's possible. Is this really how far it goes? Do I really have to do everything through Tor? Maybe I missed something. Andy
Re: Securing DNS traffic
At Mon, 25 May 2020 19:51:52 -0400, "Aaron B." wrote: Subject: Re: Securing DNS traffic > > Again, I'd prefer to run my own resolvers, but can't justify the > expense. I would recommend begging or borrowing _any_ old used computer that can run any open-source OS (though ideally NetBSD, of course) and support at least two Ethernet ports, and set it up as a firewall (with NAT) between your home network and your ISP's router. Hook the cable modem to it and run all your own networking through it. Then you can run your own DHCP server and resolver (e.g. unbound), your own NTP server, and possibly even some other services, such as SSH (perhaps on a non-standard port for the ISP-facing interface); as well as of course using it as a proper firewall too. With a WiFi card it can also be your access point. I currently use my Apple Time Capsule as the router/firewall/DHCP server and run the resolver, etc. on a cheap old used server (actually on a VM running on Xen on that cheap old used server). The time capsule is technically using NetBSD too. (Though now that Apple has dumbed down the AirPort Utility to basically cripple it, I'll soon have to migrate to a newer machine for routing -- something with better gigabit-speed throughput, as keeping the old laptop to run the old AirPort Utility is not viable.) -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgprTIEkuyggn.pgp Description: OpenPGP Digital Signature
Re: Securing DNS traffic
On Mon, 25 May 2020 12:57:59 +0200 Niels Dettenbach wrote: > I would trust my (paid) ISPs NS much more then any other "free" one by all > what i've seen in my life there - especially if your ISP grants you no usage > logging by contract. This isn't really a thing where I live. The ISP's here routinely return A records to a scammy "search engine" instead of NXDOMAIN. One was caught throttling video streaming services, so they could collect money from both the streaming services and the customers. (The fact they also sell cable TV makes that even more suspicious.) Is there anything in the contract I could use to fight this? I don't know. It's dozens of pages long and written in a way only a lawyer can understand it. There are no other choices for internet access in my area. Again, I'd prefer to run my own resolvers, but can't justify the expense. -- Aaron B.
Re: HP ProLiant server running NetBSD 9 setup suggestions?
One of the drives failed and I’d set the drives up as a single volume, oops. I brought up Windows temporarily to do the one firmware update I didn’t seem to be able to do any other way (the storage controller) and then reinstalled NetBSD. Now that I’ve reinstalled, have a dmesg: https://dmesgd.nycbug.org/index.cgi?do=view=5512 There’s going to be one more reinstall in my future, once my LFF drive cage arrives and I set up large 3.5in SATA disks. My experience so far is that putting in a random disk that I had laying around causes the fans to spin up to 70some percent for a period of time, and then the system appears to adapt to the drive and get quiet again--right now it’s barely noticeable. We’ll see what happens when I build LLVM... -- Chris
Low power system with built in GPS, WiFi?
I'm currently using a Raspberry Pi Zero with a camera for something (using raspbian), and I want to do something similar but I'm hoping to get onboard GPS. I want to run it on a battery. Also if the WiFi adapter could do hostap, this would be a bonus. Does such a thing exist? A USB camera could be used but I've never done anything with cameras and NetBSD, is it possible? The goal is to be able to stream video to another WiFi device, and possibly log GPS location. Thanks. Andy
Re: Securing DNS traffic
Sad Clouds wrote in
<20200525152338.beed20b18e42642ec3403...@gmail.com>:
|On Fri, 22 May 2020 22:38:19 +0100
|Sad Clouds wrote:
|
|> It seems there are two main security enhancements for DNS:
|>
|> 1. DNSSEC - digital signatures for DNS records to verify they haven't
|> been tampered with.
|>
|> 2. DNS over TLS - encryption of DNS traffic for privacy. This goes via
|> port 853 and could be over TCP or UDP (DTLS), although it's not clear
|> to me if both TCP and UDP are always supported, of if it's mainly TCP.
|
|I've been doing some more research and came across this article on DNS
|hijacking
|
|https://www.fireeye.com/blog/threat-research/2019/01/global-dns-hijackin\
|g-campaign-dns-record-manipulation-at-scale.html
|
|Some of the techniques they describe seem to follow these steps:
|
|1. DNS account is compromised and either A or NS records are changed to
| point to a bogus server.
|2. User connects to "email.mydomain.com" which is sent to a bogus
| server that acts as a "man in the middle", collecting credentials
| and then forwarding everything to the real "email.mydomain.com"
|
|I think TLS was designed to avoid "main in the middle" attacks, but it
|seems in this case a bogus server is using its own "valid" TLS
|certificate and then proxying connections to the real server.
|
|I don't quite understand how this works. Is it the case of somebody
|creating a second valid TLS certificate for "email.mydomain.com" in
|order to masquerade as a genuine email server? So if different CAs can
|issue such certificates, how do you mitigate such attacks? Isn't this a
|flaw in the PKI design to have different CAs that can vouch for the same
|domain?
First TLS works with a local pool of trusted certificates.
Any remote party who has a certificate that has been signed by one
of the certificates in your local CA pool is automatically
trusted.
Then DNS is a decentralized datastore with some root servers
(though in fact there are multiple "roots" as some countries do
not like that most of those root servers are in fact USA). Then
there are (local) stub resolvers (like in the C library, some of
them fully caching answers, some reissuing each and every
request), then recursive resolvers, which can fully handle DNS
with redirects and data collection etc. unless a query (of a stub
resolver or what) can be truly answered (or not, of course).
Data is organized in zones, and servers/recursive resolvers can
transfer entire zones, iirc most RFCs regarding DNS dealt with
zone transfers (by then). This localizes data and effectively
avoids lots of internet traffic.
Iirc correctly you get authoritative results from recursive
resolvers (servers) which got their data via zone transfer.
And you simply trusted the "authoritative" bit in the response.
DNSSEC extends this by offering zone administrators the
possibility to sign their data, in theory these signatures are
duplicated down and even arrive in stub resolvers, these can then
verify that the actual data is correct.
There is a tree/chain of trust among the DNS up to the root
servers, so . signs .ORG signs ME.ORG. signs *.ME.ORG. Never did
that, but think that is the thing. You can resolve that tree
downwards, verifying data you get. The certificates and the
mechanism is totally distinct from the CA pool of TLS.
Which i personally totally dislike. But especially i dislike that
CMS aka maybe x509 aka the certificates of TLS could be used for
much more, their use is artifically restricted. I do not like
that this crypto mess is torn apart and lots of different
standards are involved, and have to be audited, where one would be
sufficient. (Then you could for example just make a TLS handshake
with root servers to get the necessary info to verify that your
.ORG signature is correct, and ditto...)
Also DNS/TLS and DNS/DTLS have been standardized twenty years to
late, it should all have been designed as a unity, imho. The same
is true for UTF-8 for hostnames instead of IDNA. All imho.
You need to trust your DNS provider, twenty years ago just as well
as today. It is just that for one no man-in-the-middle can look
at the communication (TLS), and that you can cryptographically
verify that the data is really correct ("DNSSEC"). The latter
only if any parties that your DNS provider contacts ship the
signatures down along with responses, of course.
And there was EDNS ~20 years ago already, TCP should not be
necessary for neither of DNSSEC nor TLS (regarding packet size).
|Under the "Prevention Tactics" the article talks about "revoking
|malicious certificates", but what tools/methods are there to tell you
|which certificates are malicious?
--End of <20200525152338.beed20b18e42642ec3403...@gmail.com>
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: Securing DNS traffic
Am Sonntag, 24. Mai 2020, 20:02:45 CEST schrieb Aaron B.: > I'm also worried about this, but also fear datamining by my ISP. So I > completely ditched Google, and split my queries between Cloudflare and > Quad9 - neither gets the complete picture. This relys on a typical misunderstanding what most of these data collecting N services are after. "getting to know what websites / servers some single user connects to" usually not, because that would be very inefficient. If you fear that your ISP "can do that" - DNS is the wrong vector to "block that", because he can much more easily use netflow, firewall / router "logging" and similiar efficient ways to see (and collect / process) with which servers a single customer (not user) really got connected and (each time!) when (without the huge "caching blindness" of DNS) and how often / how intensive (even with SSL/TLS - except SNI / "virtual hosts", but this often can be uncovered by "traffic correlation" if really required). I would trust my (paid) ISPs NS much more then any other "free" one by all what i've seen in my life there - especially if your ISP grants you no usage logging by contract. And what i knew from Mozilla and Co., these are much less "selfless" too as their public image project it... If your ISP really cheat you - he could/would do this (as explained) without his DNS (except in some countries where local ISPs filter third party DNS at all because of "regulation", what usually means censorship...). -- --- Niels Dettenbach Syndicat IT & Internet http://www.syndicat.com PGP: https://syndicat.com/pub_key.asc ---
Re: Securing DNS traffic
Am Samstag, 23. Mai 2020, 12:09:09 CEST schrieb Sad Clouds: > I was thinking about this as well, but is there any real evidence that > public DNS providers misuse your personal data? Depends from what you "expect" as "misuse". Running "free" public NS to i.e. "just collect domain names" and "usage statistics" was/is a typical source for collectors of such data - not only "Google". I knew several projects from experience where such "application" happened, i.e. in the SEO environment, internet security service providers as similiar... niels. -- --- Niels Dettenbach Syndicat IT & Internet http://www.syndicat.com PGP: https://syndicat.com/pub_key.asc ---
Re: Securing DNS traffic
On Fri, 22 May 2020 22:38:19 +0100 Sad Clouds wrote: > It seems there are two main security enhancements for DNS: > > 1. DNSSEC - digital signatures for DNS records to verify they haven't > been tampered with. > > 2. DNS over TLS - encryption of DNS traffic for privacy. This goes via > port 853 and could be over TCP or UDP (DTLS), although it's not clear > to me if both TCP and UDP are always supported, of if it's mainly TCP. I've been doing some more research and came across this article on DNS hijacking https://www.fireeye.com/blog/threat-research/2019/01/global-dns-hijacking-campaign-dns-record-manipulation-at-scale.html Some of the techniques they describe seem to follow these steps: 1. DNS account is compromised and either A or NS records are changed to point to a bogus server. 2. User connects to "email.mydomain.com" which is sent to a bogus server that acts as a "man in the middle", collecting credentials and then forwarding everything to the real "email.mydomain.com" I think TLS was designed to avoid "main in the middle" attacks, but it seems in this case a bogus server is using its own "valid" TLS certificate and then proxying connections to the real server. I don't quite understand how this works. Is it the case of somebody creating a second valid TLS certificate for "email.mydomain.com" in order to masquerade as a genuine email server? So if different CAs can issue such certificates, how do you mitigate such attacks? Isn't this a flaw in the PKI design to have different CAs that can vouch for the same domain? Under the "Prevention Tactics" the article talks about "revoking malicious certificates", but what tools/methods are there to tell you which certificates are malicious?
Re: Securing DNS traffic
On Mon, 25 May 2020 10:17:56 +0200 Jörn Clausen wrote: > Hi! > > I was not arguing for "no security at all". It's just this motivation > for DoT/DoH (disguising the request from your ISP) that I don't get. > > I have only a cursory knowledge of these technologies, but I think > DNSSEC is the far better approach against the type of forgery you > mentioned. Why do you expect CloudFlare or any other DoH provider not > to be corrupted? I have just as much trust in them as in the > commercial VPN provider you mentioned, or my ISP for that matter: > very very little. As a European user, I definitely don't want all my > DNS traffic to be routed through a single US company by default. But > YMMV... They are different technologies that complement each other. You need both DNSSEC and DoT. You're right, any service provider could be monitoring your activity and I don't believe US vs Europe makes much difference here. I live in the UK and there has been "Data Protection Act" in place well before EU "General Data Protection Regulation". Just because something is legislated does not mean that everybody follows it to the letter. With DNSSEC you validate the integrity of the data, so if somebody managed to poison the cache of some DNS server and insert a bogus entry, hopefully DNSSEC should be able to flag it. However, if someone redirects your DNS traffic (as some ISPs do) they could completely strip out any DNSSEC data and substitute whatever records they like. For example when you type "site.nosuchtld" into your web browser, instead of an error, you get a web page filled with ads or some other nonsense. With DoT you nominate some trusted DNS server and TLS certificate validation should flag if someone attempts to impersonate that server. It's up to you which server to trust CloudFlare, Google or your own that you setup in some trusted data centre.
Re: Securing DNS traffic
Hi! I was not arguing for "no security at all". It's just this motivation for DoT/DoH (disguising the request from your ISP) that I don't get. I have only a cursory knowledge of these technologies, but I think DNSSEC is the far better approach against the type of forgery you mentioned. Why do you expect CloudFlare or any other DoH provider not to be corrupted? I have just as much trust in them as in the commercial VPN provider you mentioned, or my ISP for that matter: very very little. As a European user, I definitely don't want all my DNS traffic to be routed through a single US company by default. But YMMV... On Sun, May 24, 2020 at 11:22 PM Sad Clouds wrote: > On Sun, 24 May 2020 20:55:29 +0200 > Jörn Clausen wrote: > > > I simply don't get how this is a use case for DoT or DoH. Even if you > > disguise the DNS lookup, the next packet you send will be directed to > > the address you just looked up. Unless this happens to be a virtual > > hosting service, it is quite clear to your ISP what you are doing. I > > recommend this talk by Paul Vixie > > There is always potential for surveillance. You may think you're safe > on a VPN, but if you didn't setup the endpoints yourself, on your own > hardware, how can you trust some VPN provider 100%? You can't. > > I think the value of DoT is to stop DNS traffic hijacking and > redirection. Even if you configure /etc/resolv.conf to point to some > trusted DNS server, your ISP (or anyone else) can surreptitiously > redirect it to their own DNS server for various purposes (tracking, > filtering, serving ads, etc). Yes there are other ways to track people, > but the less info you leak in plain text the better. > -- Joern Clausen https://www.oe-files.de/photography/
