[opensuse-security] nss-mdns and SuSEfirewall2
Hello, I am trying to resolve the name of my printer via nss-mdns. It works fine with "avahi-resolve -n KY623B6B.local". But "ping KY623B6B.local" does not work because the SuSEfirewall2 blocks the incoming answers from port 5353 of the printer to a random port of my computer. The avahi service opens upd and broadcast on port 5353 but not answers from port 5353. Using FW_ALLOW_INCOMING_HIGHPORTS_UDP="mdns" makes "ping KY623B6B.local" working but that option is deprecated ... Gruß Jan -- If you make people think they're thinking, they'll love you. But if you really make them think they'll hate you. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Jan Ritzerfeld wrote:
I am trying to resolve the name of my printer via nss-mdns. It works fine with "avahi-resolve -n KY623B6B.local". But "ping KY623B6B.local" does not work because the SuSEfirewall2 blocks the incoming answers from port 5353 of the printer to a random port of my computer. The avahi service opens upd and broadcast on port 5353 but not answers from port 5353. Using FW_ALLOW_INCOMING_HIGHPORTS_UDP="mdns" makes "ping KY623B6B.local" working but that option is deprecated ...
Yes. That option is dangerous. Anyone can access your UDP ports above 1024 now. That includes for example rpc services and the mdns daemon itself. Put the interface into the INT Zone instead and get used to trusting your LAN. FW_ALLOW_INCOMING_HIGHPORTS_UDP just gives you a false sense of security. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Am Dienstag, 23. September 2008 schrieb Ludwig Nussel:
Jan Ritzerfeld wrote:
I am trying to resolve the name of my printer via nss-mdns. It works fine with "avahi-resolve -n KY623B6B.local". But "ping KY623B6B.local" does not work because the SuSEfirewall2 blocks the incoming answers from port 5353 of the printer to a random port of my computer. The avahi service opens upd and broadcast on port 5353 but not answers from port 5353. Using FW_ALLOW_INCOMING_HIGHPORTS_UDP="mdns" makes "ping KY623B6B.local" working but that option is deprecated ...
Yes. That option is dangerous. Anyone can access your UDP ports above 1024 now.
Oh, you are right. This is clearly not what I wanted.
That includes for example rpc services and the mdns daemon itself.
However, the strange part for me is that "avahi-resolve -n KY623B6B.local" works fine. The summary of nss-mdns tells me that it would use a running avahi deamon. I have a avahi deamon running, but nss-mdns tries to resolve the name via mdns by itself. And failes, because of the firewall.
Put the interface into the INT Zone instead and get used to trusting your LAN. FW_ALLOW_INCOMING_HIGHPORTS_UDP just gives you a false sense of security.
Well, the LAN connected by the interface is connected to the Internet, too. Thus, I thought the EXT zone would be correct and I have to distinguish the internal traffic by the source IP address. Yes, I know, this is somewhat weak, too. However, the internet router should filter all packets with internal addresses that come from the internet. As /etc/sysconfig/SuSEfirewall2 tells me, I want to use something like FW_SERVICES_ACCEPT_RELATED_EXT="192.168.1.0/24,udp,,mdns" since the destination port is arbitrary. But there is no mdns conntrack module that could mark the answers to the multicast packets as related. Argh. I do not know what happend. But today, "ping KY623B6B.local" works out of the box without using FW_ALLOW_INCOMING_HIGHPORTS_UDP. However, "rcnscd stop" and the nss-mdns resolution will stop working, too. "rcnscd start" and it will work again ... Gruß Jan -- Nobody really knows what is going on anywhere in your organization. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Jan Ritzerfeld wrote:
However, the strange part for me is that "avahi-resolve -n KY623B6B.local" works fine. The summary of nss-mdns tells me that it would use a running avahi deamon. I have a avahi deamon running, but nss-mdns tries to resolve the name via mdns by itself. And failes, because of the firewall.
try "echo mdns off >> /etc/host.conf". There is a patch in glibc that make glibc itself resolve the .local zone instead of using nss_mdns.
Put the interface into the INT Zone instead and get used to trusting your LAN. FW_ALLOW_INCOMING_HIGHPORTS_UDP just gives you a false sense of security.
Well, the LAN connected by the interface is connected to the Internet, too. Thus, I thought the EXT zone would be correct and I have to distinguish the internal traffic by the source IP address. Yes, I know, this is somewhat weak, too. However, the internet router should filter all packets with internal addresses that come from the internet.
You could use FW_TRUSTED_NETS or FW_SERVICES_ACCEPT_EXT to allow only the IP range of your LAN.
As /etc/sysconfig/SuSEfirewall2 tells me, I want to use something like FW_SERVICES_ACCEPT_RELATED_EXT="192.168.1.0/24,udp,,mdns" since the destination port is arbitrary. But there is no mdns conntrack module that could mark the answers to the multicast packets as related.
Exactly. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Am Mittwoch, 24. September 2008 schrieb Ludwig Nussel:
Jan Ritzerfeld wrote:
However, the strange part for me is that "avahi-resolve -n KY623B6B.local" works fine. The summary of nss-mdns tells me that it would use a running avahi deamon. I have a avahi deamon running, but nss-mdns tries to resolve the name via mdns by itself. And failes, because of the firewall.
try "echo mdns off >> /etc/host.conf". There is a patch in glibc that make glibc itself resolve the .local zone instead of using nss_mdns.
Oh, I assumed that this patch was replaced/obsoleted by nss-mdns. Wouldn't it be a good idea either to add "mdns off" when installing nss-mdns automatically, or to remove the glibc patch?
[...] You could use FW_TRUSTED_NETS or FW_SERVICES_ACCEPT_EXT to allow only the IP range of your LAN. [...]
You convinced me of adding my internal IP range to FW_TRUSTED_NETS. :) Gruß Jan -- Les États-Unis d'Amérique forment un pays qui est passé directement de la barbarie à la décadence, sans jamais avoir connu la civilisation. -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Jan Ritzerfeld wrote:
Am Mittwoch, 24. September 2008 schrieb Ludwig Nussel:
However, the strange part for me is that "avahi-resolve -n KY623B6B.local" works fine. The summary of nss-mdns tells me that it would use a running avahi deamon. I have a avahi deamon running, but nss-mdns tries to resolve the name via mdns by itself. And failes, because of the firewall.
Jan Ritzerfeld wrote: try "echo mdns off >> /etc/host.conf". There is a patch in glibc that make glibc itself resolve the .local zone instead of using nss_mdns.
Oh, I assumed that this patch was replaced/obsoleted by nss-mdns. Wouldn't it be a good idea either to add "mdns off" when installing nss-mdns automatically, or to remove the glibc patch?
I'd also prefer if the default configuration wouldn't ship with this LINK_LOCAL and MDNS crap. At least a checkbox in the network configuration to switch it off easily. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Michael Ströder wrote:
Jan Ritzerfeld wrote:
Am Mittwoch, 24. September 2008 schrieb Ludwig Nussel:
However, the strange part for me is that "avahi-resolve -n KY623B6B.local" works fine. The summary of nss-mdns tells me that it would use a running avahi deamon. I have a avahi deamon running, but nss-mdns tries to resolve the name via mdns by itself. And failes, because of the firewall.
Jan Ritzerfeld wrote: try "echo mdns off >> /etc/host.conf". There is a patch in glibc that make glibc itself resolve the .local zone instead of using nss_mdns.
Oh, I assumed that this patch was replaced/obsoleted by nss-mdns. Wouldn't it be a good idea either to add "mdns off" when installing nss-mdns automatically, or to remove the glibc patch?
I'd also prefer if the default configuration wouldn't ship with this LINK_LOCAL and MDNS crap. At least a checkbox in the network configuration to switch it off easily.
Well, file a bug report (enhancement). On 11.1 the glibc mdns patch is disabled AFAIK. The mdns_minimal module relies on avahi so stopping the avahi daemon should be sufficient to disable mdns. OTOH avahi does at least have a cache for positive name lookups so I'd expect less problems due to timeouts. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
participants (3)
-
Jan Ritzerfeld -
Ludwig Nussel -
Michael Ströder