Bug 1754530
Summary: | [Security] FreeIPA server installer should lock Bind9 recursion and allow to configure it | |||
---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Cédric Jeanneret <cjeanner> | |
Component: | freeipa | Assignee: | IPA Maintainers <ipa-maint> | |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
Severity: | medium | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 30 | CC: | abokovoy, diego.abelenda, fcami, fdc, ipa-maint, jcholast, jhrozek, pvoborni, rcritten, ssorce, twoerner | |
Target Milestone: | --- | |||
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | If docs needed, set a value | ||
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1798877 (view as bug list) | Environment: | ||
Last Closed: | 2020-02-05 19:17:33 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1798877 |
Description
Cédric Jeanneret
2019-09-23 13:41:39 UTC
I think we can add recursion ACL support to bind-dyndb-ldap and read it from LDAP from server object like we do with forwarder policy already in 'ipa dnsserver-mod --forward-policy'. That would be just about perfect. I wasn't sure ACL could be integrated in the dyndb-ldap - not sure if we can set them dynamically without any service reload. Hello, This issue is a bit of a problem since freeipa is authoritative for the zone it manages and also recursive for everybody. So you cannot firewall your DNS port, and cannot filter using ACL. This is an annoying security problem that I discovered just now... Do you have an idea on when this will be possible to manage ACLs in dyndb-ldap? Best regards, Diego Abelenda There work on this is currently not planned. I did look at the code and it is a bit complex to add something like this right now. We also need to work on updates for newer bind version as it did change API quite a lot. On the other hand, BIND 9.4.1-P1 and above does default to only allow recursion for 'localnets; locahost;'. See https://kb.isc.org/docs/aa-00269, so it should already be set to a safer default. Hello, I deployed a brand new freeIPA with Fedora 30 - I don't have access to the install right now, but I can confirm that the resolver IS widely open with that version. The named.conf file has "allow-recursion {"any;};" in it, and I could resolve any host from anywhere. Maybe the installer itself overrides the default? Would be good to at least mention it at the end of the deploy or, even better, override it in a better way, using a static ACL block in the file so that operators can, at least, add new subnets if needed. The dyndb-ldap thing is a good idea, but as you wrote, it might be complicated, and current install might be a security threat on the world wide web.... Maybe a first step is to already lock down thing with the named.conf and a proper changelog/notice? Thank you for your investigations and feedback, Alexander :) Cheers, C. Hello, I found out that the installer contains a template for the config of bind9 which will open recursion to any -> https://github.com/freeipa/freeipa/blob/master/install/share/bind.named.conf.template#L12 Best regards, Diego Abelenda Hey, Thanks Diego - after some more researches: https://github.com/freeipa/freeipa/commit/5f4c75eb28b3d50a35fbf3a86a6d842bce8e72f9 https://pagure.io/freeipa/issue/1335 Setting this by default is, at least nowadays, plain wrong. It might still be set, but maybe using an invasive option like "--yes-i-really-want-to-be-insecure" or something? This, at least, would ensure new deploy would be secured (or opened if the right option is passed), without much work imho. As proposed in the initial report, allowing to pass an option like: --dns-trusted-nets x.x.x.x/24,y.y.y.y/16,2001::2/48 would allow to populate a proper ACL. Not dynamic for sure, but that would ensure complete management from the Operator side. Also, it might be good to manage in the same patchset the allow-query-cache and lock it down to the very same ACL... What do you think? I'm also concerned about update, since it will most certainly override the named.conf and re-open locked down resolvers :/. Not really good on a security side... Cheers, C. You are right, Cédric. The template for bind.conf has this: install/share/bind.named.conf.template: allow-recursion { any; }; So I think an easiest solution for new deployments would be to actually remove this line. May be you can submit a pull request at https://github.com/freeipa/freeipa ? I can do that, yes. Is it the right place though? It's apparently a mirror.. ? Hello, Note that this behaviour is apparently documented: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/install-server See the "Preventing DNS Amplification Attacks" section of this page... I find it really weird that the it is documented that the default configuration is to allow amplification attacks and you need to change it to be secure... Best regards, Diego Abelenda (In reply to Cédric Jeanneret from comment #10) > I can do that, yes. Is it the right place though? It's apparently a mirror.. > ? Please see https://www.freeipa.org/page/Contribute/Code#Create_pull_request_on_Github -- we use github mirror only for pull requests handling (and CI integration). Hello Alex, PR on its way (added to the links at the top of this issue). Please let me know if it's OK for you and the FreeIPA Team - of course, I can rework it if needed. Thank you for your time! Cheers, C. PS: can't move it to "ON_DEV" apparently... ? This would break existing behavior for clients from other subnets than the IPA servers. See https://bugzilla.redhat.com/show_bug.cgi?id=713798#c2 for background information. Being insecure by default is not a good idea. The "natural" setup for kerberos would be having a publicly reachable DNS with zone delegation thus making FreeIPA an authoritative DNS for the zone (also because you could also have your users' machines in the kerberos realm for SSO, like an AD setup). Some Registrars disallow a Recursive DNS to be referenced as NS server of the zone but for most users they will have a recursive DNS as their NS server without noticing (like me). This "insecure by default" behaviour is not what you would expect because it "just works" and would expect the default to be somewhat secure. In the "no recursion" setup, you will have problems only in a weird setup where the authoritative DNS server is private and also recursive DNS for the organization. In my opinion, this should not be the recommended way to setup freeipa even if it is possible. We had a discussion between me, Christian and Cédric. A short outcome: - we would like to add 'ipa-ext.conf' include file for named. This file will contain only comments in the default installation but will be included from named.conf - we'll remove default recursion statement from the named.conf. This means on bind9 since 9.4.1-P1 we would default to allow recursion only on localhost and localnets. - anything else can be added by admins to ipa-ext.conf which will not be overridden on upgrades - the file 'ipa-ext.conf' will need to be backed up and restored properly, it should have correct rights, SELinux policy, etc That will give us a way to close the issue down fast and allow extensions for something else that admins want to add as well. For the future, we'll work on adding support for recursion acls to bind-dyndb-ldap so that they can be stored in LDAP per server. Fixed with https://pagure.io/freeipa/c/bbe2472324c140a22aad6d272733fc6d434782ef?branch=ipa-4-8 in FreeIPA 4.8.2+ |