Re: BIND, nsupdate and acme.sh DNS authentication
On 7/23/20 9:13 PM, Brett Delmage wrote: To get this topic back on topic for this list: When you are creating Let's Encrypt wildcard certificates you must use a DNS authenticiation protocol with letsencrypt. I am using the acme.sh client which was recommended for wildcard certificates. https://github.com/acmesh-official/acme.sh If you are running your own nameserver you also need to enable dynamic updates so that the acme.sh client can create TXT records during certificate acqusition and renewal. However I have found that getting zone dynamic updates (authentication, specifically) working with nsupdate (which acme.sh uses) and BIND have been a PITA. I haven't been overly impressed with the debug capabilities to help get nsupdate working properly. Interesting, I wasn't aware of this. Looking at Manjaro's site again, I found that their main website indeed uses a wildcard certificate while the forum (which was affected by the certificate renewal issues if memory serves me right) uses its own dedicated cert. Granted these renewal issues were already a few years ago so perhaps they changed some things here and there by now. I had heard of Let's Encrypt's wildcard certs but never looked further into it. Would certainly be useful though, as subdomains are an easy way to separate services. Unfortunately bacme (which I currently use) doesn't seem to support the DNS-based ACME challenges. I've cloned the acme.sh repository and will look further into it. -- Met vriendelijke groet / Best regards, Michael De Roover ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND, nsupdate and acme.sh DNS authentication
On Thu, 23 Jul 2020, Michael De Roover wrote: For example I don't trust Manjaro's maintainers, since they screwed up their TLS certificate renewal no less than 3 times. That's complete and utter incompetence on their part. How they didn't already put certbot in a cron job after the first time is beyond me. To get this topic back on topic for this list: When you are creating Let's Encrypt wildcard certificates you must use a DNS authenticiation protocol with letsencrypt. I am using the acme.sh client which was recommended for wildcard certificates. https://github.com/acmesh-official/acme.sh If you are running your own nameserver you also need to enable dynamic updates so that the acme.sh client can create TXT records during certificate acqusition and renewal. However I have found that getting zone dynamic updates (authentication, specifically) working with nsupdate (which acme.sh uses) and BIND have been a PITA. I haven't been overly impressed with the debug capabilities to help get nsupdate working properly. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
On 7/23/2020 7:44 AM, charlie derr wrote: While it would still *technically* be security by obscurity, it would seem to me that there's some value to this approach because access to the compiled binary wouldn't necessarily be easy to obtain (especially if the sysadmin provisioning the system takes extra efforts to *not* share it with anyone). Or am i missing something? I don't think there is much value because getting access isn't only done by buffer overflows and such on compiled programs. If you can find one then sure you might be able to get root access if the program you break into is running at root. But you can do an awful lot of damage by merely having unprivileged access. All you need is authentication credentials and regular users are horrible about keeping their credentials private. In fact the only place I can see a whole lot of value to is the manufacturers of cell phones since companies like Verizon lock the boot loaders as they do not wish owners of their phones to root them and get rid of annoying Verizon advertising and other suchlike. Rooting those devices is mainly done by breaking into security holes on the phone. Ted ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
On Thu, 23 Jul 2020, charlie derr wrote: On 7/23/20 9:49 AM, Michael De Roover wrote: [...] For this to work at all though, they'd have to provide all packages simply as source code (why not use the distribution's own source repositories?) and compile it on the target. [...] While it would still *technically* be security by obscurity, it would seem to me that there's some value to this approach because access to the compiled binary wouldn't necessarily be easy to obtain (especially if the sysadmin provisioning the system takes extra efforts to *not* share it with anyone). Or am i missing something? They actually run a very large build farm in AWS, and they claim that all binaries are made just for you. Basically you change your distro's package repositories to theirs. Preventing people from examining the binaries in order to craft working memory exploits which work across a large installed base is exactly what they're aiming to prevent. Disclosure: I've heckled their CTO in a friendly fashion for making better idiots, but I paid for my own Old Fashioned. -- Fred Morris ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
On 7/23/20 10:44 AM, charlie derr wrote: > Caveat: i'm far from an expert on compiling, linking, disassembling, > etc... (in fact i know *very* little about these domains), so it's > possible my comment/question below won't even really make sense. > > Still, i'm not going to learn more without asking, so... > > On 7/23/20 9:49 AM, Michael De Roover wrote: >> The idea is pretty interesting, seems like they provide a repository >> with packages compiled with their own compiler that changes various >> memory-related elements. It is true that memory is usually the culprit >> behind security flaws. Nevermind my previous question, obviously i didn't read carefully enough (sonce their repo would expose the compiled binaries). /back to lurk mode ~c ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
Caveat: i'm far from an expert on compiling, linking, disassembling, etc... (in fact i know *very* little about these domains), so it's possible my comment/question below won't even really make sense. Still, i'm not going to learn more without asking, so... On 7/23/20 9:49 AM, Michael De Roover wrote: > The idea is pretty interesting, seems like they provide a repository > with packages compiled with their own compiler that changes various > memory-related elements. It is true that memory is usually the culprit > behind security flaws. > > According to their page at > https://polyverse.com/products/polymorphing-linux-security/ : > > "Polymorphing takes source code and runs it through a polymorphic > compiler, changing register usage, function locations, import tables and > other targets. This produces individually unique binaries that are > semantically equivalent to the source. Polymorphing applies the compiler > to the totality of the Linux stack." > > For this to work at all though, they'd have to provide all packages > simply as source code (why not use the distribution's own source > repositories?) and compile it on the target. But even then I think it's > more of a security by obscurity thing. Sure it makes it more difficult > to exploit a memory flaw by means of automated exploits and other such > scripts. But nothing stops you from taking the unmodified source code, > the binary and a disassembler to find out how exactly the resulting > binary has been changed / polymorphed. While it would still *technically* be security by obscurity, it would seem to me that there's some value to this approach because access to the compiled binary wouldn't necessarily be easy to obtain (especially if the sysadmin provisioning the system takes extra efforts to *not* share it with anyone). Or am i missing something? > I'm not very familiar with > reverse engineering and disassemblers but I don't think there's much > more to it than that, at least to thwart this defense. All of it is > possible if an attacker can read, retrieve and execute a binary on the > affected server. The flaws are still there, only their memory locations > have changed. It would probably defend against script kiddies, but I > doubt it would keep out a determined attacker. > > Personally I prefer Google's approach to this for Chromium. They > documented it at > https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md > . Implementing programs in memory safe languages where possible is > something I believe to be a more solid long-term solution. Additionally > Google's Project Zero team is behind a lot of the security research and > disclosures. They audit the actual code instead, which I believe to be > far more suitable. > > While the idea is valid to some extent (and could be worth it in highly > confidential environments), I wouldn't consider it worth compiling > everything from source for, with a nonstandard compiler no less. If > servers would just be updated more often and (security) bug fixes > actually make their way through to the distribution releases reliably, > we'd already go a long way I think. Of course there are also > configuration mistakes that could compromise a network component. From > what I've seen so far, this seems to be more often the case with those > leaked databases and whatnot. Thanks much for this fascinating discussion, ~c > > On 7/23/20 2:39 PM, Fred Morris wrote: >> Perhaps slightly OT, but here's a company which has a whole business >> model based on one nonobvious (?) reason to compile from source: >> https://polyverse.com/ >> >> -- >> >> Fred Morris -- Charlie Derr Director, Instructional Technology 413-528-7344 https://www.simons-rock.edu Bard College at Simon's Rock Encryption key: http://hope.simons-rock.edu/~cderr/ Personal writing: https://medium.com/@cderr Pronouns: he or they Home landline: 860-435-1427 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
The idea is pretty interesting, seems like they provide a repository with packages compiled with their own compiler that changes various memory-related elements. It is true that memory is usually the culprit behind security flaws. According to their page at https://polyverse.com/products/polymorphing-linux-security/ : "Polymorphing takes source code and runs it through a polymorphic compiler, changing register usage, function locations, import tables and other targets. This produces individually unique binaries that are semantically equivalent to the source. Polymorphing applies the compiler to the totality of the Linux stack." For this to work at all though, they'd have to provide all packages simply as source code (why not use the distribution's own source repositories?) and compile it on the target. But even then I think it's more of a security by obscurity thing. Sure it makes it more difficult to exploit a memory flaw by means of automated exploits and other such scripts. But nothing stops you from taking the unmodified source code, the binary and a disassembler to find out how exactly the resulting binary has been changed / polymorphed. I'm not very familiar with reverse engineering and disassemblers but I don't think there's much more to it than that, at least to thwart this defense. All of it is possible if an attacker can read, retrieve and execute a binary on the affected server. The flaws are still there, only their memory locations have changed. It would probably defend against script kiddies, but I doubt it would keep out a determined attacker. Personally I prefer Google's approach to this for Chromium. They documented it at https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md . Implementing programs in memory safe languages where possible is something I believe to be a more solid long-term solution. Additionally Google's Project Zero team is behind a lot of the security research and disclosures. They audit the actual code instead, which I believe to be far more suitable. While the idea is valid to some extent (and could be worth it in highly confidential environments), I wouldn't consider it worth compiling everything from source for, with a nonstandard compiler no less. If servers would just be updated more often and (security) bug fixes actually make their way through to the distribution releases reliably, we'd already go a long way I think. Of course there are also configuration mistakes that could compromise a network component. From what I've seen so far, this seems to be more often the case with those leaked databases and whatnot. On 7/23/20 2:39 PM, Fred Morris wrote: Perhaps slightly OT, but here's a company which has a whole business model based on one nonobvious (?) reason to compile from source: https://polyverse.com/ -- Fred Morris -- Met vriendelijke groet / Best regards, Michael De Roover ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
Perhaps slightly OT, but here's a company which has a whole business model based on one nonobvious (?) reason to compile from source: https://polyverse.com/ -- Fred Morris ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
If you're running Alpine, you should know that it uses MUSL which has a stub resolver which is/was lacking in some respects: http://postfix.1071664.n5.nabble.com/Outgoing-DANE-not-working-tp105397p105420.html On Thu, 23 Jul 2020, Michael De Roover wrote: [...] With my internal BIND servers now running on Alpine (because super lightweight), that blurs the lines a bit. -- Fred Morris ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
On Tue, Jul 21, 2020 at 4:24 AM @lbutlr wrote: > > On 20 Jul 2020, at 11:45, Ted Mittelstaedt wrote: > > When FreeBSD was used mostly for servers it wasn't a problem. But more > > and more people are using it for desktop use where they want to basically > > install it and forget about it, never run patches, never give > > a fig about security. > > Bind is a poor choice for desktop use. Packages like unbound are much better > for that sort of use, and it is fr less critical if those packages have > security issues. > I was taught in kitty school "less critical if those packages have security issues" is never a good argument. Just because getting-into-a-desktop-and-then-using-it-as-launchpad-to-go-after-servers is a traditional Windows attack vector does not mean Linux computers are immune of that. > I agree that anyone using a FreeBSD install as a server should be using bind, > but I also agree it should not be the default install. You install bind when > you figure out you need it, and not before. > > > > -- > Mickey and Mallory know the difference between right and wrong; the > just don't give a damn. > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
On 7/23/20 7:19 AM, Ted Mittelstaedt wrote: Well for starters there is no way for ME to validate that the compiled software you built for me isn't busy running your Doom network server behind my back. (do people still even run Doom servers?) People would find out when an unnecessary service is started up though, no? Especially with services, you can see those with netstat/ss right away. Additionally, the distribution maintainers are (or at least should be) the ones compiling it. It could be argued that by installing their distribution, there is already a certain level of trust being given to said maintainers. For example I don't trust Manjaro's maintainers, since they screwed up their TLS certificate renewal no less than 3 times. That's complete and utter incompetence on their part. How they didn't already put certbot in a cron job after the first time is beyond me. On the other hand, I have started to get fond of Debian.. though also not entirely. But enough to consider that their packages are probably just fine. I could also verify this by compiling it myself and comparing the result. They publish their downstream source code along with any modifications they made. You are making an argument that is a desktop argument. That is, the argument goes Those That Know Better Will Do It For You. Not quite, rather my goals for the system sufficiently align with those of the distribution I end up going with on this or that system. And on a server I don't like compiling from source for the same reason that I wouldn't install and run a desktop environment on it. I consider it unnecessary cruft. And keeping those packages up-to-date... I forgot to manually update software I built from a git repository more often than I'd like to admit. I also lost count. With my internal BIND servers now running on Alpine (because super lightweight), that blurs the lines a bit. With 9.14.12, they ship an EOL version of BIND. And their stock configuration for it was pretty much unusable anyway. Everything on that was replaced. Compiling from source or sticking with what they provide, perhaps notifying Alpine's maintainers that they should look into it? I don't know. But compiling 9.16 ESV there probably wouldn't be a bad idea. Certainly doable, but not as convenient. Also, I have had at least 5 Open Source programs over the years that I found Really Useful to have that the authors decided they wanted to "take commercial" or they had other religious conversions that made them decide to go on a rampage and issue take down notices everywhere they could find their source. One of those for example was when Nasty-Company-Who-Shall-Not-Be-Graced-With-A-Mention decided to start charging for software that created .gif files and the graphics community went on a ballistic rampage jihad and destroyed every scrap of .gif code it could find so as to force users to migrate to .png. I did not wish to migrate to .png so I was very glad that I had saved all the old code, safe from the fires of the religious zealots. That's an issue of licensing, it is super annoying, and having older source code still available in those cases is indeed really useful. I don't know how relevant this is to this discussion though (granted, can we still pretend to be on-topic anyway?) given that this is more about open source projects merely providing binary packages (with the source available), rather than said project completely denying source code access. Regarding the ballistic rampage... I can't help but think that this is what's happening in BIND right now. Fortunately it was only a few days worth of commits that dealt with.. that totally 100% necessary change of nomenclature. Lastly, the way I look at it is when I field a new server, if it cannot recompile it's OS, kernel, make world, and all of it's applications from source, then it's a piece of excrement that I do not want in service. It is also a fact that I have had pre-production servers blow up on "make worlds" In a few cases this was bad ram, in one case the server was returned to the manufacturer under warranty. These are machines that did not display any issues before the OS load. Do not ask me why it was possible to install all the binaries for the OS and have it boot with no problems yet blow chunks/blue screen/abend/take a dive into the toilet/whatever your preferred term for crashing and burning is. I don't generally run FreeBSD or Linux as a desktop OS, BTW so that does affect my view of things. So yes, there is definitely an argument in favor of compiling the stuff at least on a server. Fair points. And I agree, having the option is absolutely something I wouldn't want to give away for proprietary software either. But in all the software I use (be it on workstations or servers, I run Linux on both) I do have that option. It's just not as convenient and I certainly wouldn't want every distro to turn into a Gentoo for
