Bug 909430

Summary:

Filter out inappropriate multicast and subnet broadcast addresses from dynamic DNS update

Product:

Red Hat Enterprise Linux 7

Reporter:

Kaleem <ksiddiqu>

Component:

sssd

Assignee:

Jakub Hrozek <jhrozek>

Status:

CLOSED CURRENTRELEASE

QA Contact:

Kaushik Banerjee <kbanerje>

Severity:

unspecified

Docs Contact:

Priority:

medium

Version:

7.0

CC:

abokovoy, dpal, error, grajaiya, jgalipea, jhrozek, mkosek, nikolai.kondrashov, nsoman, pbrezina, pspacek

Target Milestone:

Target Release:

7.0

Hardware:

Unspecified

OS:

Unspecified

Whiteboard:

Fixed In Version:

sssd-1.10.0-1.el7.alpha1

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Clones:

990143 (view as bug list)

Environment:

Last Closed:

2014-06-13 10:11:35 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:

990143, 1009914

Attachments:

Description	Flags
output of multicast-broadcast scenarios	none

Description Kaleem 2013-02-08 18:13:01 UTC

Created attachment 695207 [details]
output of multicast-broadcast scenarios

Description of problem:

Multicast and subnet broadcast addresses are not being filtered out from IPA dynamic dns update While this works for loopback/link-local addresses.

Version-Release number of selected component (if applicable):
[root@rhel64client1 ~]# rpm -q sssd
sssd-1.9.2-82.el6.x86_64
[root@rhel64client1 ~]#

How reproducible:
Always.

Additional info:
https://bugzilla.redhat.com/show_bug.cgi?id=790105

Comment 2 Jakub Hrozek 2013-02-08 18:34:36 UTC

The broadcast addresses might be hard/not needed except for 255.255.255.255 which is already handled, but I have a patch for the multicast part.

Comment 3 Jakub Hrozek 2013-02-08 18:37:17 UTC

Upstream ticket:
https://fedorahosted.org/sssd/ticket/1804

Comment 6 Jakub Hrozek 2013-03-26 18:14:00 UTC

Fixed upstream.

Comment 7 Michael Hampton 2013-07-30 06:51:57 UTC

Any chance of getting this bugfix in EL6? This is causing dynamic DNS address updates for RFC1918 A records to randomly fail.

Comment 8 Alexander Bokovoy 2013-07-30 06:58:24 UTC

We really need this in RHEL 6. IN_MULTICAST(addr) is not the same as IN_MULTICAST(ntohl(addr)) on Intel architecture.As result of wrong byte order many innocent addresses are filtered out.

Comment 9 Petr Spacek 2013-07-30 11:52:37 UTC

AFAIK it doesn't make much sense to filter IPv4 multicast addresses, because they are not considered valid *source* addresses. Multicast address is valid only as *destination* address, so no multicast address should ever appear on the IPv4 interface.

Comment 10 Jakub Hrozek 2013-10-04 13:22:56 UTC

Temporarily moving bugs to MODIFIED to work around errata tool bug

Comment 12 Kaleem 2014-01-20 09:44:03 UTC

Now mutilcast address is filtered out for dynamic dns update but still i do see that subnet/network broadcast address is not filtered out.

sssd version:
=============
[root@rhel70-client ~]# rpm -q sssd ipa-client
sssd-1.11.2-27.el7.x86_64
ipa-client-3.3.3-12.el7.x86_64
[root@rhel70-client ~]#

(A)Multicast address:
=====================
Multicast address is now filtered.

(Mon Jan 20 14:56:26 2014) [sssd[be[testrelm.com]]] [ok_for_dns] (0x0200): Multicast IPv4 address 224.0.0.1
(Mon Jan 20 14:56:26 2014) [sssd[be[testrelm.com]]] [ok_for_dns] (0x0200): Link local IPv6 address fe80::5054:ff:fe53:8842
(Mon Jan 20 14:56:26 2014) [sssd[be[testrelm.com]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry

(B)Subnet/Network broadcast address:
====================================
Subnet/Network broadcast address is still not filtered out.

[root@rhel70-client ~]# ifconfig eth1
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.65.207.255  netmask 255.255.255.255  broadcast 0.0.0.0
        inet6 fe80::5054:ff:fe53:8842  prefixlen 64  scopeid 0x20<link>
        inet6 2620:52:0:41ce:5054:ff:fe53:8842  prefixlen 128  scopeid 0x0<global>
        ether 52:54:00:53:88:42  txqueuelen 1000  (Ethernet)
        RX packets 13046  bytes 920984 (899.3 KiB)
        RX errors 0  dropped 1  overruns 0  frame 0
        TX packets 99  bytes 14615 (14.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
[root@rhel70-client ~]# cat /etc/sssd/sssd.conf|grep dyn
ipa_dyndns_update = True
ipa_dyndns_iface = eth1 
[root@rhel70-client ~]# cat /etc/sssd/sssd.conf|grep debug
debug_level = 0x200
[root@rhel70-client ~]# service sssd restart
Redirecting to /bin/systemctl restart  sssd.service
[root@rhel70-client ~]#

Snippet from /var/log/sssd/sssd_testrelm.com.log
=================================================
[delayed_online_authentication_callback] (0x0200): Backend is online, starting delayed online authentication.
(Mon Jan 20 15:03:47 2014) [sssd[be[testrelm.com]]] [ok_for_dns] (0x0200): Link local IPv6 address fe80::5054:ff:fe53:8842
(Mon Jan 20 15:03:47 2014) [sssd[be[testrelm.com]]] [nsupdate_msg_create_common] (0x0200): Creating update message for realm [TESTRELM.COM].
(Mon Jan 20 15:03:47 2014) [sssd[be[testrelm.com]]] [be_nsupdate_create_fwd_msg] (0x0200): Setting the zone explicitly to [testrelm.com].

On IPA Master:
==============
[root@rhel70-master ~]# ipa dnsrecord-show testrelm.com rhel70-client
  Record name: rhel70-client
  A record: 10.65.207.23, 10.65.207.255
  AAAA record: 2620:52:0:41ce:5054:ff:fe53:8842
  SSHFP record: 1 1 CEB17DACECD029C48B35594530BFF62884267BC2, 1 2 56ED178C60713B89F33E02BC7616CEE542EB0CB23BADA707E24DC73D B47C2E60, 3 1
                8A20A32B13DE641007897009A0118A2BF880E888, 3 2 B8DC5AB48671AB2FEE985AFF34D161DB57272A90F98595806F4CBCDA B30F4275
[root@rhel70-master ~]#

Comment 13 Petr Spacek 2014-01-20 12:46:36 UTC

(In reply to Kaleem from comment #12)
> [root@rhel70-client ~]# ifconfig eth1
> eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>         inet 10.65.207.255  netmask 255.255.255.255  broadcast 0.0.0.0

Please note that there are no network and broadcast addresses if the netmask length is >= 31. See RFC 3021 - http://tools.ietf.org/html/rfc3021.

Please verify that filtering works for netmask lengths <= 29.

Comment 14 Kaleem 2014-01-21 08:25:26 UTC

(In reply to Petr Spacek from comment #13)
> Please note that there are no network and broadcast addresses if the netmask
> length is >= 31. See RFC 3021 - http://tools.ietf.org/html/rfc3021.
> 
> Please verify that filtering works for netmask lengths <= 29.

I tried with netmask length 28 and still see same behaviour.

[root@rhel70-client ~]# cat /etc/sssd/sssd.conf|grep dyn
ipa_dyndns_update = True
ipa_dyndns_iface = ens6 
[root@rhel70-client ~]# ifconfig ens6
ens6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.65.207.255  netmask 255.255.255.240  broadcast 0.0.0.0
        inet6 2620:52:0:41ce:5054:ff:fec8:44b7  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::5054:ff:fec8:44b7  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:c8:44:b7  txqueuelen 1000  (Ethernet)
        RX packets 3241  bytes 182703 (178.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 241  bytes 40926 (39.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@rhel70-client ~]# service sssd restart
Redirecting to /bin/systemctl restart  sssd.service
[root@rhel70-client ~]#

(Tue Jan 21 12:45:58 2014) [sssd[be[testrelm.com]]] [delayed_online_authentication_callback] (0x0200): Backend is online, starting delayed online authentication.
(Tue Jan 21 12:45:58 2014) [sssd[be[testrelm.com]]] [ok_for_dns] (0x0200): Link local IPv6 address fe80::5054:ff:fec8:44b7
(Tue Jan 21 12:45:58 2014) [sssd[be[testrelm.com]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry


[root@rhel70-client ~]# ipa dnsrecord-show testrelm.com rhel70-client
  Record name: rhel70-client
  A record: 10.65.207.21, 10.65.207.255
  AAAA record: 2620:52:0:41ce:5054:ff:fec8:44b7
  SSHFP record: 1 1 CEB17DACECD029C48B35594530BFF62884267BC2, 1 2 56ED178C60713B89F33E02BC7616CEE542EB0CB23BADA707E24DC73D B47C2E60, 3 1
                8A20A32B13DE641007897009A0118A2BF880E888, 3 2 B8DC5AB48671AB2FEE985AFF34D161DB57272A90F98595806F4CBCDA B30F4275
[root@rhel70-client ~]#

Comment 15 Michael Hampton 2014-01-21 15:22:45 UTC

(In reply to Kaleem from comment #14)
> ens6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>         inet 10.65.207.255  netmask 255.255.255.240  broadcast 0.0.0.0

An IPv4 address with 255 as the final octet is valid for hosts when the prefix is <= 23. In such a case it is not actually the broadcast address. Thus a naïve test for 255 as the final octet would filter out valid addresses.

When the IP address and prefix are invalid, as in the last two examples, I'm surprised the kernel lets you configure this at all. I would have expected an error to be thrown. But that's a separate issue...

Comment 16 Petr Spacek 2014-01-21 17:07:45 UTC

(In reply to Kaleem from comment #14)
> I tried with netmask length 28 and still see same behaviour.
I don't know what the log message tries to tell me, please contact somebody from SSSD, it may be bug.

Comment 17 Jakub Hrozek 2014-02-06 12:31:44 UTC

Nikolai, can you check out this bug for me, please? I'm in meetings most of this week.

Comment 18 Nikolai Kondrashov 2014-02-25 13:48:12 UTC

Kaleem, implementing filtering of subnet broadcast addresses would require considerable changes to the code (i.e. transferring netmask along with the address), while the benefit of such protection is very low, as broadcast addresses have no valid purpose of appearing on an interface.

Probability of such addresses being unintentionally added to an interface (say by mistake or due to a bug) is very low, and sssd cannot protect against intentional addition of such records to DNS anyway, as there are other ways to do that (say with nsupdate).

Even if such records are added to DNS, it doesn't seem to present much danger.

Thus, I propose sssd doesn't handle this case.

Comment 19 Kaleem 2014-03-10 09:30:38 UTC

(In reply to Nikolai Kondrashov from comment #18)
> Kaleem, implementing filtering of subnet broadcast addresses would require
> considerable changes to the code (i.e. transferring netmask along with the
> address), while the benefit of such protection is very low, as broadcast
> addresses have no valid purpose of appearing on an interface.
> 
> Probability of such addresses being unintentionally added to an interface
> (say by mistake or due to a bug) is very low, and sssd cannot protect
> against intentional addition of such records to DNS anyway, as there are
> other ways to do that (say with nsupdate).
> 
> Even if such records are added to DNS, it doesn't seem to present much
> danger.
> 
> Thus, I propose sssd doesn't handle this case.

Ok then turning bug to verified state as per comment 12 .

Comment 20 Jakub Hrozek 2014-03-20 14:43:42 UTC

*** Bug 1009914 has been marked as a duplicate of this bug. ***

Comment 21 Ludek Smid 2014-06-13 10:11:35 UTC

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.