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
