Bug 1754530 - [Security] FreeIPA server installer should lock Bind9 recursion and allow to configure it
Summary: [Security] FreeIPA server installer should lock Bind9 recursion and allow to ...
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: freeipa
Version: 30
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: IPA Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-09-23 13:41 UTC by Cédric Jeanneret
Modified: 2019-09-26 15:12 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Fedora Pagure 8079 None None None 2019-09-26 15:12:38 UTC
Github freeipa freeipa pull 3725 'None' 'closed' 'Ensure recursion is locked when deploying DNS service' 2019-11-25 08:52:29 UTC

Description Cédric Jeanneret 2019-09-23 13:41:39 UTC
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.

Comment 1 Alexander Bokovoy 2019-09-23 14:07:07 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'.

Comment 2 Cédric Jeanneret 2019-09-23 14:17:19 UTC
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.

Comment 3 diego.abelenda 2019-09-24 10:00:05 UTC
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

Comment 4 Alexander Bokovoy 2019-09-24 10:58:59 UTC
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.

Comment 5 Alexander Bokovoy 2019-09-24 11:00:52 UTC
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.

Comment 6 Cédric Jeanneret 2019-09-24 11:05:52 UTC
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.

Comment 7 diego.abelenda 2019-09-24 11:15:19 UTC
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

Comment 8 Cédric Jeanneret 2019-09-24 11:22:50 UTC
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.

Comment 9 Alexander Bokovoy 2019-09-24 11:36:10 UTC
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 ?

Comment 10 Cédric Jeanneret 2019-09-24 11:48:14 UTC
I can do that, yes. Is it the right place though? It's apparently a mirror.. ?

Comment 11 diego.abelenda 2019-09-24 12:01:15 UTC
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

Comment 12 Alexander Bokovoy 2019-09-24 12:04:21 UTC
(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).

Comment 13 Cédric Jeanneret 2019-09-24 12:08:59 UTC
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... ?

Comment 14 François Cami 2019-09-24 12:19:30 UTC
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.

Comment 15 diego.abelenda 2019-09-24 12:31:53 UTC
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.

Comment 16 Alexander Bokovoy 2019-09-24 13:12:34 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.