Description of problem: Currently, when we install FreeIPA server with DNS support, it configures Bind9 for full, unlimited recursion. This is a really bad idea, especially since it's not mentioned by the installer. A good idea would be to create an ACL block such as: acl recursion_net { 127.0.0.0/24; ::1/64; }; and allow recursion only for this recursion_net. This would allow to actually configure the allowed network, for instance if the IPA is being deployed in some internal network and should allow the LAN to make recursive calls. Of course we can go and edit the named.conf file, then restart named-pkcs11 service. But when we update the service (yum update), we will then have conflicts, and this prevents automated updates (for instance, with an ansible playbooks). If FreeIPA had a way to actually configure an ACL properly, that would make things really easier. How reproducible: Always Steps to Reproduce: 1. deploy a freeIPA server 2. try `dig @your-ipa.tld www.google.com' 3. profit Actual results: The recursion does work without any limitation Expected results: The recursion should be prevented, by default only localhost should be allowed.
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+