Ludwig, sorry for bothering you, but what do you think of this feature?

Hey, Christian, welcome to the club.
What does the openSUSE comunity (you) think of this issue :)?
Have you seen anything about Firewall vs. Broadcast (SLP Browsing) in opensuse mails, forums, wiki...?

(In reply to comment #2)
> Hey, Christian, welcome to the club.

;-)

> Have you seen anything about Firewall vs. Broadcast (SLP Browsing) in 
> opensuse mails, forums, wiki...?

Not that I knew of - at least in suse-{linux,security} and opensuse{,-factory}. But the reason may be that SLP is (IMHO) rarely used in small environments - and in large companies the network is (hopefully ;-) trusted enough to shutdown the firewall on internal machines.
And: If SLP is used, then it will be for installation in many cases - there isn't a firewall in this stage yet ;-)

That said: I think your idea is very good. Why should one need to shutdown the whole firewall just to open a single port?

Question: AFAIK Samba machine browsing uses broadcasts and requires the firewall to be shutdown (or Samba in the internal zone) for machine listings etc. Would the implementation of your idea also allow firewalled samba broadcasts (with the required ports open, of course)?
If yes, then we found something that was asked several times already ;-)

Considering the SLP, firewall is turned 'on' by default, that's why we have to deal with it. Compared to a Windows-based network, I'd still leave it running in a bigger network (but that's always a philosophical question).

SLP can be also used when searching for NTP server or for another network installation source. It's used on several places in YaST.

Considering Samba, this example above was about SLP, on the other hand if anybody could describe how Samba communicates, which ports and protocols are used for what, it shouldn't be problem to adjust the expert rule for that. So the enhancement could be renamed :)

The setting you suggest doesn't open one udp port. It opens all udp ports, an attacker just has to send the packets so that they originate from port 427. So it doesn't make sense to introduce any SLP special here. You could add an option to configure "trusted ip ranges" per zone instead if you want to. e.g FW_SERVICES_ACCEPT_EXT="10.10.0.0/16". A protocol is currently required but I can make it optional.

Yes I know, but defining port 427 limits the possibility for attacker. The attacker also doesn't know when I want to browse the network, that's the other limitation (and sending tones of packets to port 427 all the time would be hopefully found by a Network Administrator).

The rule could be better defined as:
X.Y.0.0/255.255.248.0,udp,1025:65535,427

This rule would open only high UDP ports :) Well, there still migh be running some service on a high UDP port. That still CAN be protected :) netstat shows what is listening where :)...

Yeah, there is always a way to make it even more complicated and obscure.

Security by obscurity :)

This commands prints all port numbers that are occupied by running (listening) UDP services, sorted:
netstat --listening --numeric --inet --udp 2>/dev/null | sed 's/[^:]\+:\([^ \t]\+\).*/\1/' | sort --numeric-sort | uniq

So a rule for opening the broadcast reply would open port ranges that don't involve ports listed above (higher than 1024, 1-1024 would stay protected).

But Ludwig is right that it maybe doesn't make sense to have a firewall turned on a trusted (browsable) network, despite the fact that I always prefer having firewall running even if it makes things harder.

jsrain, visnov:
The basic question is - Are we interested in any (or some) kind(s) of browsing the network with firewall turned on? Does it make sense? The solution might be i bit hacky, but there is always at least some 'possibility' how to do it.

Maybe a FaTE request would help, maybe broadcast (+ accepting broadcast reply) support in iptables would be a better solution (not a hacky one).

@#8: It makes sense even on trusted network. The reason may be laptops which may contain some malware infection got when connected somewhere else. Anyway, the rules should not be that strict...

@#9: accepting bcast reply seems to me to be the best solution

Jiri, could you, please, file a FATE request and mention the request number here?

Postponing after some decision is made.

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

Possible solution for broadcast reply:

--- cut ---
To browse smb shares from your linux system whilst iptables is running you'll
have to load the "ip_conntrack_netbios_ns" module. This allows netbios
broadcasts sent from your system back through the firewall:

modprobe ip_conntrack_netbios_ns

To have this loaded each time iptables starts add this to
/etc/sysconfig/iptables-config:
IPTABLES_MODULES="ip_conntrack_netbios_ns"
--- cut ---

Lukas

Is comment #15 supposed to work for SLE 10 as well? I ask because this is a very common issue on SLED 10 and I tried the suggestion in comment #15 but it didn't work.

Yes, Joe, we have the same base-system for all our products based on Linux.

Nevertheless this must be evaluated by the security team (particularly Lnussel).

(In reply to comment #17)
> Yes, Joe, we have the same base-system for all our products based on Linux.

Well, the reason I asked is because the 10.2 code is newer than SLE 10 base and since it was supposed to be working on 10.2 I just didn't know if it was something that only went into 10.2 and might go into the SLE SP1 base or some other option. And if it wasn't planned for the SP1 then I would like to get it pushed in that direction.

Actually, "Broadcast with Firewall turned on" doesn't work on any SUSE Linux, openSUSE, SLES, NLD, SLE or SLD and never worked.

If you are interested in it, please, push it forward :) Thanks

OK, this seems to be WONTFIX...
Anyway, the FATE request still remains.