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