RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 909430 - Filter out inappropriate multicast and subnet broadcast addresses from dynamic DNS update
Summary: Filter out inappropriate multicast and subnet broadcast addresses from dynami...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: 7.0
Assignee: Jakub Hrozek
QA Contact: Kaushik Banerjee
URL:
Whiteboard:
: 1009914 (view as bug list)
Depends On:
Blocks: 990143 1009914
TreeView+ depends on / blocked
 
Reported: 2013-02-08 18:13 UTC by Kaleem
Modified: 2020-05-02 17:16 UTC (History)
11 users (show)

Fixed In Version: sssd-1.10.0-1.el7.alpha1
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 990143 (view as bug list)
Environment:
Last Closed: 2014-06-13 10:11:35 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
output of multicast-broadcast scenarios (4.81 KB, text/plain)
2013-02-08 18:13 UTC, Kaleem 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 2846 0 None closed Filter out inappropriate multicast and subnet broadcast addresses from IPA dynamic DNS update 2020-05-02 17:16:20 UTC

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.
Note You need to log in before you can comment on or make changes to this bug.