[opensuse-factory] Integration of firewalld?
Hi, I wonder: did anybody look at integrating firewalld (a firewall service daemon with D-BUS interface managing a dynamic firewall), or proposing a similar dbus API for what we have? I'm starting to see some applications making use of the dbus API, and it does improve user experience to have that. https://fedoraproject.org/wiki/FirewallD/ https://fedorahosted.org/firewalld/ Thanks, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Vincent Untz wrote:
I wonder: did anybody look at integrating firewalld (a firewall service daemon with D-BUS interface managing a dynamic firewall), or proposing a similar dbus API for what we have?
Like this? http://lizards.opensuse.org/2009/07/10/1453/ http://lizards.opensuse.org/2009/08/28/firewall-zone-switcher-updated/
I'm starting to see some applications making use of the dbus API,
For what purpose?
and it does improve user experience to have that.
What exactly? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le lundi 01 août 2011, à 14:03 +0200, Ludwig Nussel a écrit :
Vincent Untz wrote:
I wonder: did anybody look at integrating firewalld (a firewall service daemon with D-BUS interface managing a dynamic firewall), or proposing a similar dbus API for what we have?
Like this? http://lizards.opensuse.org/2009/07/10/1453/ http://lizards.opensuse.org/2009/08/28/firewall-zone-switcher-updated/
I'm unsure if this covers the exact same use case; see below for an example of how firewalld is being used.
I'm starting to see some applications making use of the dbus API,
For what purpose?
and it does improve user experience to have that.
What exactly?
For instance, when configuring printers, the tool can open the mdns, ipp, ipp-client and samba-client ports for 5 minutes and probe the network (ports will get closed after the 5 minutes). And if the user chooses to use a printer using one of those ports, the tool will permanently open the port. That's the example that is implemented I'm aware of (implemented in two places), and I can see this being integrated in the vnc server, and various multimedia servers too. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Vincent Untz wrote:
Le lundi 01 août 2011, à 14:03 +0200, Ludwig Nussel a écrit :
Vincent Untz wrote:
I wonder: did anybody look at integrating firewalld (a firewall service daemon with D-BUS interface managing a dynamic firewall), or proposing a similar dbus API for what we have?
Like this? http://lizards.opensuse.org/2009/07/10/1453/ http://lizards.opensuse.org/2009/08/28/firewall-zone-switcher-updated/
I'm unsure if this covers the exact same use case; see below for an example of how firewalld is being used.
I'm starting to see some applications making use of the dbus API,
For what purpose?
and it does improve user experience to have that.
What exactly?
For instance, when configuring printers, the tool can open the mdns, ipp, ipp-client and samba-client ports for 5 minutes and probe the network (ports will get closed after the 5 minutes). And if the user chooses to use a printer using one of those ports, the tool will permanently open the port.
Well, I could implement something like that for SuSEfirwall2/fwzs (using service definitions instead of ports though) but I'm not sure it's good behavior anyways. Users are not supposed to punch holes in the external zone just because they wanted to print once. That would permanently expose cupsd after all. It would be better to switch to a trusted zone that allows e.g. printing in the first place instead. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, Im using 12.3 milestone3/factory I clicked on a .flv or .mp4 file to play it and i get the following message: Install additional codecs - kaffeine "Kaffeine currently cannot play some file formats. Do you want to install additional support?" I press install and get: The software to install could not be found in the currently enabled software repositories.It may be located in other repositories. See http://help.opensuse.org/ksuseinstall for details. Do you want to configure your repositories? Question The software to install could not be found in the currently enabled software repositories.It may be located in other repositories. See http://help.opensuse.org/ksuseinstall for details. Do you want to configure your repositories? I went to this page [1][2] and performed steps in [3] It did not work, how can it be fixed ? Thanks Glenn [1]http://opensuse-community.org/Restricted_Formats [2]http://opensuse-community.org/Restricted_formats/Tumbleweed [3]Steps done out of [2] Clicked on http://opensuse-community.org/codecs-kde.ymp Got message: The install link or file you opened does not contain instructions for this version of openSUSE. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 08/01/2011 01:04 AM, doiggl@velocitynet.com.au pecked at the keyboard and wrote: You have hi-jacked an existing email thread and may not get a response to your question. PLEASE, DoNot hit reply to a message and simply change the "Subject" line to send a message to this list, that is thread hi-jacking. There are settings in the headers of the emails (in this case: In-Reply-To: <4E36A37C.7020608@suse.de>) that help people "group" emails into "threads" so that we can keep a specific subject matter together. If you start a message on this list please start with a fresh email by using your compose button instead of reply. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 01/08/2011 15:00, Ludwig Nussel a écrit :
Well, I could implement something like that for SuSEfirwall2/fwzs (using service definitions instead of ports though) but I'm not sure it's good behavior anyways. Users are not supposed to punch holes in the external zone just because they wanted to print once.
it's somewhat necessary only for printers detection and no more after that jdd -- http://www.dodin.net http://pizzanetti.fr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le lundi 01 août 2011 à 16:28 +0200, jdd a écrit :
Le 01/08/2011 15:00, Ludwig Nussel a écrit :
Well, I could implement something like that for SuSEfirwall2/fwzs (using service definitions instead of ports though) but I'm not sure it's good behavior anyways. Users are not supposed to punch holes in the external zone just because they wanted to print once.
it's somewhat necessary only for printers detection and no more after that
Not only for printers. We have several locations in Yast which states "you might need to lower / punch firewall for this autodetection to work". It would be better for an usuability PoV for Yast to talk to the firewall and punch it just for the autodetection. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Frederic Crozat wrote:
Le lundi 01 août 2011 à 16:28 +0200, jdd a écrit :
Le 01/08/2011 15:00, Ludwig Nussel a écrit :
Well, I could implement something like that for SuSEfirwall2/fwzs (using service definitions instead of ports though) but I'm not sure it's good behavior anyways. Users are not supposed to punch holes in the external zone just because they wanted to print once.
it's somewhat necessary only for printers detection and no more after that
Not only for printers. We have several locations in Yast which states "you might need to lower / punch firewall for this autodetection to work". It would be better for an usuability PoV for Yast to talk to the firewall and punch it just for the autodetection.
The need for that will mostly vanish as soon as network connections (rather then network interfaces) have firewall zones attached. When connecting to a new network NM would ask whether you are connected to e.g. your home network or some untrusted public one. The former choice would just map to the internal zone ie no filtering, therefore no problems. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le mardi 02 août 2011 à 08:54 +0200, Ludwig Nussel a écrit :
Frederic Crozat wrote:
Le lundi 01 août 2011 à 16:28 +0200, jdd a écrit :
Le 01/08/2011 15:00, Ludwig Nussel a écrit :
Well, I could implement something like that for SuSEfirwall2/fwzs (using service definitions instead of ports though) but I'm not sure it's good behavior anyways. Users are not supposed to punch holes in the external zone just because they wanted to print once.
it's somewhat necessary only for printers detection and no more after that
Not only for printers. We have several locations in Yast which states "you might need to lower / punch firewall for this autodetection to work". It would be better for an usuability PoV for Yast to talk to the firewall and punch it just for the autodetection.
The need for that will mostly vanish as soon as network connections (rather then network interfaces) have firewall zones attached. When connecting to a new network NM would ask whether you are connected to e.g. your home network or some untrusted public one. The former choice would just map to the internal zone ie no filtering, therefore no problems.
Except : - it is not there yet - we should still be installing and enabling a firewall by default, even the one in internal zone : a lot of home users are currently using DSL / cable modem / routers which are "protecting" them with NAT but as soon as the NAT goes down (restarting the modem in factory setting) or with IPv6 becoming more and more prevalent, relying on internal zone isn't a good idea (for a company network, I agree it is "safe"). - current yast tools behavior is still screaming "I'm broken, unbroke me to get the function you want", from a usability PoV. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Frederic Crozat wrote:
Le mardi 02 août 2011 à 08:54 +0200, Ludwig Nussel a écrit :
Frederic Crozat wrote:
Le lundi 01 août 2011 à 16:28 +0200, jdd a écrit :
Le 01/08/2011 15:00, Ludwig Nussel a écrit :
Well, I could implement something like that for SuSEfirwall2/fwzs (using service definitions instead of ports though) but I'm not sure it's good behavior anyways. Users are not supposed to punch holes in the external zone just because they wanted to print once.
it's somewhat necessary only for printers detection and no more after that
Not only for printers. We have several locations in Yast which states "you might need to lower / punch firewall for this autodetection to work". It would be better for an usuability PoV for Yast to talk to the firewall and punch it just for the autodetection.
The need for that will mostly vanish as soon as network connections (rather then network interfaces) have firewall zones attached. When connecting to a new network NM would ask whether you are connected to e.g. your home network or some untrusted public one. The former choice would just map to the internal zone ie no filtering, therefore no problems.
Except : - it is not there yet - we should still be installing and enabling a firewall by default, even the one in internal zone : a lot of home users are currently using DSL / cable modem / routers which are "protecting" them with NAT but as soon as the NAT goes down (restarting the modem in factory setting) or with IPv6 becoming more and more prevalent, relying on internal zone isn't a good idea (for a company network, I agree it is "safe").
Let's accept your assumption that home routers would actually route all traffic into your network for a moment. That would mean opening some port, even for a little while is even more wrong. You'd expose your cups/avahi/rpc ports not only to the local network but the whole internet! So you'd have to restrict access to your local IP range at which point things get difficult to squeeze into a usable UI. Esp with v6 where you get multiple, dynamically assigned and potentially even changing prefixes depending on connectivity (e.g. ULAs if router is offline). So either the router takes care of filtering traffic or the network really is untrusted in which case you don't want to suggest the user to open ports.
- current yast tools behavior is still screaming "I'm broken, unbroke me to get the function you want", from a usability PoV.
Well, feel free to file bugs against yast modules that are broken in that regard. No need to wait for firewalld. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le mardi 02 août 2011 à 10:55 +0200, Ludwig Nussel a écrit :
Frederic Crozat wrote:
Le mardi 02 août 2011 à 08:54 +0200, Ludwig Nussel a écrit :
Frederic Crozat wrote:
Le lundi 01 août 2011 à 16:28 +0200, jdd a écrit :
Le 01/08/2011 15:00, Ludwig Nussel a écrit :
Well, I could implement something like that for SuSEfirwall2/fwzs (using service definitions instead of ports though) but I'm not sure it's good behavior anyways. Users are not supposed to punch holes in the external zone just because they wanted to print once.
it's somewhat necessary only for printers detection and no more after that
Not only for printers. We have several locations in Yast which states "you might need to lower / punch firewall for this autodetection to work". It would be better for an usuability PoV for Yast to talk to the firewall and punch it just for the autodetection.
The need for that will mostly vanish as soon as network connections (rather then network interfaces) have firewall zones attached. When connecting to a new network NM would ask whether you are connected to e.g. your home network or some untrusted public one. The former choice would just map to the internal zone ie no filtering, therefore no problems.
Except : - it is not there yet - we should still be installing and enabling a firewall by default, even the one in internal zone : a lot of home users are currently using DSL / cable modem / routers which are "protecting" them with NAT but as soon as the NAT goes down (restarting the modem in factory setting) or with IPv6 becoming more and more prevalent, relying on internal zone isn't a good idea (for a company network, I agree it is "safe").
Let's accept your assumption that home routers would actually route all traffic into your network for a moment. That would mean opening some port, even for a little while is even more wrong. You'd expose your cups/avahi/rpc ports not only to the local network but the whole internet! So you'd have to restrict access to your local IP range at which point things get difficult to squeeze into a usable UI. Esp with v6 where you get multiple, dynamically assigned and potentially even changing prefixes depending on connectivity (e.g. ULAs if router is offline).
So either the router takes care of filtering traffic or the network really is untrusted in which case you don't want to suggest the user to open ports.
From what I see, such routers aren't common in SOHO market (and I'm not sure they will be in the near future). And I'm not convinced explaining those concepts to average users (or even a SOHO admin) will be successful.
- current yast tools behavior is still screaming "I'm broken, unbroke me to get the function you want", from a usability PoV.
Well, feel free to file bugs against yast modules that are broken in that regard. No need to wait for firewalld.
Ok, I'll open bug reports for those. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On Aug 2 11:11 Frederic Crozat wrote (excerpt):
And I'm not convinced explaining those concepts to average users (or even a SOHO admin) will be successful.
From my experience is this the real problem.
In other words: I think the real problem with any kind of firewall setup is to make the basic concepts behind understood by the user who must make a reasonable decision for his particular environment. Please no knee-jerk proposal to "autodetect his particular environment and setup 'the right thing' automatically" ;-) I think this is a really hard usability problem. By the way: http://lists.opensuse.org/opensuse-ux/ Are usability problems still somehow addressed nowadays? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Aug 02, 2011 at 11:11:21AM +0200, Frederic Crozat wrote:
Le mardi 02 août 2011 à 10:55 +0200, Ludwig Nussel a écrit : [ 8< ]
Let's accept your assumption that home routers would actually route all traffic into your network for a moment. That would mean opening some port, even for a little while is even more wrong. You'd expose your cups/avahi/rpc ports not only to the local network but the whole internet! So you'd have to restrict access to your local IP range at which point things get difficult to squeeze into a usable UI. Esp with v6 where you get multiple, dynamically assigned and potentially even changing prefixes depending on connectivity (e.g. ULAs if router is offline).
So either the router takes care of filtering traffic or the network really is untrusted in which case you don't want to suggest the user to open ports.
From what I see, such routers aren't common in SOHO market (and I'm not sure they will be in the near future). And I'm not convinced explaining those concepts to average users (or even a SOHO admin) will be successful.
IPv6 enabled Integrated Access Devices (IAD) are more and more common. Also more and more Internet Service Providers (ISP) have v6 on the agenda. For Germany they're also driven by the decision of Deutsche Telekom to offer v6 to all customers till end of 2011. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
Le mardi 02 août 2011 à 14:15 +0200, Lars Müller a écrit :
On Tue, Aug 02, 2011 at 11:11:21AM +0200, Frederic Crozat wrote:
Le mardi 02 août 2011 à 10:55 +0200, Ludwig Nussel a écrit : [ 8< ]
Let's accept your assumption that home routers would actually route all traffic into your network for a moment. That would mean opening some port, even for a little while is even more wrong. You'd expose your cups/avahi/rpc ports not only to the local network but the whole internet! So you'd have to restrict access to your local IP range at which point things get difficult to squeeze into a usable UI. Esp with v6 where you get multiple, dynamically assigned and potentially even changing prefixes depending on connectivity (e.g. ULAs if router is offline).
So either the router takes care of filtering traffic or the network really is untrusted in which case you don't want to suggest the user to open ports.
From what I see, such routers aren't common in SOHO market (and I'm not sure they will be in the near future). And I'm not convinced explaining those concepts to average users (or even a SOHO admin) will be successful.
IPv6 enabled Integrated Access Devices (IAD) are more and more common.
Also more and more Internet Service Providers (ISP) have v6 on the agenda. For Germany they're also driven by the decision of Deutsche Telekom to offer v6 to all customers till end of 2011.
Agreed (my own ISP Free.fr is one of the first big ISP to enable IPv6 on its IAD years ago) but I'm not sure those IAD will have filtering capabilities for IPv6. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Frederic Crozat wrote:
Le mardi 02 août 2011 à 14:15 +0200, Lars Müller a écrit :
On Tue, Aug 02, 2011 at 11:11:21AM +0200, Frederic Crozat wrote:
Le mardi 02 août 2011 à 10:55 +0200, Ludwig Nussel a écrit : [ 8< ]
Let's accept your assumption that home routers would actually route all traffic into your network for a moment. That would mean opening some port, even for a little while is even more wrong. You'd expose your cups/avahi/rpc ports not only to the local network but the whole internet! So you'd have to restrict access to your local IP range at which point things get difficult to squeeze into a usable UI. Esp with v6 where you get multiple, dynamically assigned and potentially even changing prefixes depending on connectivity (e.g. ULAs if router is offline).
So either the router takes care of filtering traffic or the network really is untrusted in which case you don't want to suggest the user to open ports.
From what I see, such routers aren't common in SOHO market (and I'm not sure they will be in the near future). And I'm not convinced explaining those concepts to average users (or even a SOHO admin) will be successful.
IPv6 enabled Integrated Access Devices (IAD) are more and more common.
Also more and more Internet Service Providers (ISP) have v6 on the agenda. For Germany they're also driven by the decision of Deutsche Telekom to offer v6 to all customers till end of 2011.
Agreed (my own ISP Free.fr is one of the first big ISP to enable IPv6 on its IAD years ago) but I'm not sure those IAD will have filtering capabilities for IPv6.
Well, I seriously hope so. While we can come up with creative firewall solutions for openSUSE other devices found in home networks certainly wouldn't have them. After all nowadays not only printers have network connectivity themselves but also TV's, radios and even cameras. I doubt Joe Average expects them to be hack^Wreachable from the Internet by default. It's the job of the router to prevent that. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 02/08/2011 10:55, Ludwig Nussel a écrit :
Let's accept your assumption that home routers would actually route all traffic into your network for a moment. That would mean opening some port, even for a little while is even more wrong. You'd expose your cups/avahi/rpc ports not only to the local network but the whole internet!
thats wrong. We don't speak opening the internet router firewall, but the client station firewall. I don't think we ever speak of detecting printers on the internet... my ISP box have two interfaces: extenal (to the ISP server in the phone company building) and internal (my private network and the printer) so it's only a security problem if you have a malicious gest at the time you configure the printer. Be also aware that if you don"'t do this, the user simply drop completely the firewall during the config, wich is worst IMHO jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On Aug 2 12:32 jdd wrote (excerpt):
We don't speak opening the internet router firewall, but the client station firewall. ... my ISP box have two interfaces: extenal (to the ISP server in the phone company building) and internal (my private network and the printer)
I assume that "private network" also means "trusted network". If I understand you correctly, I wonder why you need a firewall on client stations in an trusted internal network? In other words:
From what do you like to protect client stations in a trusted network?
Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 02/08/2011 14:21, Johannes Meixner a écrit :
If I understand you correctly, I wonder why you need a firewall on client stations in an trusted internal network?
the wiki page quoted in the beginning say that it's always better to have one jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Aug 2 14:37 jdd wrote (excerpt):
Le 02/08/2011 14:21, Johannes Meixner a écrit :
If I understand you correctly, I wonder why you need a firewall on client stations in an trusted internal network?
the wiki page quoted in the beginning say that it's always better to have one
Yes, http://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings reads "to be on the safe side ... when whatever kind of server process was started by accident" but there is also -------------------------------------------------------------------- If your host is connected only to a trusted internal network where a dedicated firewall machine protects the whole internal network, you may switch off the firewall on your host. ... If your router-box supports private IP addresses together with NAT (and if there is no security flaw in the router-box), your hosts are in a trusted internal network where the the router-box is a dedicated firewall machine which protects your whole internal network so that you may even switch off the firewall on your hosts (provided you trust your router-box). ... When the CUPS print server process is the only server process which runs on the workstation, opening its IPP port 631 removes effectively any firewall protection from the workstation. -------------------------------------------------------------------- I was asking "from what do you like to protect client stations in a trusted network?" I meant against which actual threats (describe some examples please) do you like to protect your client stations when you run a firewall in your trusted network but open ports for the services which you use in your trusted network? Doing this removes effectively any firewall protection so that there is no reason to have the firewall at all. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
Le mercredi 03 août 2011, à 09:03 +0200, Johannes Meixner a écrit :
When the CUPS print server process is the only server process which runs on the workstation, opening its IPP port 631 removes effectively any firewall protection from the workstation.
This is assuming that there is no non-root processes opening ports above 1024, which is not necessarily true. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello Vincent, On Aug 3 09:07 Vincent Untz wrote (excerpt):
Le mercredi 03 août 2011, à 09:03 +0200, Johannes Meixner a écrit :
When the CUPS print server process is the only server process which runs on the workstation, opening its IPP port 631 removes effectively any firewall protection from the workstation.
This is assuming that there is no non-root processes opening ports above 1024, which is not necessarily true.
I do not understand what you mean. I meant: When a "whatever" server process is the only server process which runs on the workstation, opening its port removes effectively any firewall protection from the workstation. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
Le mercredi 03 août 2011, à 09:33 +0200, Johannes Meixner a écrit :
Hello Vincent,
On Aug 3 09:07 Vincent Untz wrote (excerpt):
Le mercredi 03 août 2011, à 09:03 +0200, Johannes Meixner a écrit :
When the CUPS print server process is the only server process which runs on the workstation, opening its IPP port 631 removes effectively any firewall protection from the workstation.
This is assuming that there is no non-root processes opening ports above 1024, which is not necessarily true.
I do not understand what you mean.
I meant: When a "whatever" server process is the only server process which runs on the workstation, opening its port removes effectively any firewall protection from the workstation.
My point is that you cannot assume it's the only server process, as there might be applications running for a user, that also listen on ports. This is an easy assumption to make when you only consider system services, but it's harder to evaluate if it's true if you consider all apps running on a computer. So, sure, if only one server process runs, this is true. My point is that you cannot assume that there is only one server process. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On Aug 3 09:41 Vincent Untz wrote (excerpt):
My point is that you cannot assume it's the only server process
Of course. http://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings ----------------------------------------------------------------------- ... to be on the safe side you should not switch off the firewall because it will protect your host against unwanted access via network when whatever kind of server process was started by accident. In contrast if one or more server processes are running on your host and you open their matching ports in the firewall, you remove any firewall protection from your host because you only need a firewall to protect running server processes against unwanted access via network. ----------------------------------------------------------------------- Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 2 August 2011 13:21, Johannes Meixner <jsmeix@suse.de> wrote:
my ISP box have two interfaces: extenal (to the ISP server in the phone company building) and internal (my private network and the printer)
I assume that "private network" also means "trusted network".
If I understand you correctly, I wonder why you need a firewall on client stations in an trusted internal network?
In other words: From what do you like to protect client stations in a trusted network?
One incident that comes from personal experience, was in a "trusted" company network. Basically I got port scanned from the Internet Gateway host, which caused a minor incident, certainly some alarm until the scan was explained. Furthermore in any shared network, you may be exposed by others with different requirements. As a result it became clear that a "trusted" corporate network, wasn't really to be trusted. Some effort was warranted, pro Practical security is a trade off, and is a multi-layer thing; so I could quite imagine apparently contradictory requirements of wishing to use some auto-discovery, then operate with minimal permissions once the service is found. Remember the most secure computer is the one that's turned off, turning it on is a risk but necessary to actually get something done with it. Regards Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On Aug 2 18:13 Rob Davies wrote (excerpt):
One incident that comes from personal experience, was in a "trusted" company network. Basically I got port scanned from the Internet Gateway host
If you have the ports open in the firewall for the services which you use in your internal network, the firewall would not help you against a port scan or against any kind of attack regarding the services which you use in your internal network. If you use services in your internal network, you cannot protect them with firewalls inside your internal network. You can only protect your whole trusted network with a firewall at the borderline of your trusted network. If the protection at the borderline fails you are basically doomed. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 03/08/2011 09:31, Johannes Meixner a écrit :
If the protection at the borderline fails you are basically doomed.
the discussion is a bit off topic, but very intéresting, it's a good occasion to revise knowledge As I see it, dsl box firewall simply close any port (don't forward any). So a break only break the box/router. To open the network this should allow arbitrary forward. I hope if any hardware router have such flaw, the maker will react fast! The internet is full of robots charging any server all the day (my online server have frightening logs :-), so my main fear if against childs installing whaever they have at hand on windows machines, including virtual networks for games. Do anybody know example of Linux computer compromised in such a way? the only real life threat I know is pirates trying to use mail servers, and I know I will very fast notice this thanks jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 3 August 2011 08:31, Johannes Meixner <jsmeix@suse.de> wrote:
On Aug 2 18:13 Rob Davies wrote (excerpt):
One incident that comes from personal experience, was in a "trusted" company network. Basically I got port scanned from the Internet Gateway host
If you have the ports open in the firewall for the services which you use in your internal network, the firewall would not help you against a port scan or against any kind of attack regarding the services which you use in your internal network.
If you use services in your internal network, you cannot protect them with firewalls inside your internal network.
You can only protect your whole trusted network with a firewall at the borderline of your trusted network.
If the protection at the borderline fails you are basically doomed.
Actually I arranged to explicitly enable host IP addresses requiring access, detecting "unauthorised" accesses. Furthermore I took advantage of the subnetting. Resigning oneself to "being doomed" is not a practical option, it certainly won't enhance your reputation with the managers who allocate the department budgets.. You can for instance arrange for a peer's DNS or NTP server UDP packets to pass, but generally block UDP on that interface as illegitimate. There is a general problem with idea of "trusted", it is far too black & white when reality hits. BTW Someone mentioned ssh, sshd can listen on alternative ports to 22, that seems actually a wise step from the ssh port probing I've seen. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On Aug 3 11:19 Rob Davies wrote (excerpt):
On 3 August 2011 08:31, Johannes Meixner <jsmeix@suse.de> wrote:
If you use services in your internal network, you cannot protect them with firewalls inside your internal network.
You can only protect your whole trusted network with a firewall at the borderline of your trusted network.
If the protection at the borderline fails you are basically doomed.
Actually I arranged to explicitly enable host IP addresses requiring access, detecting "unauthorised" accesses. Furthermore I took advantage of the subnetting. ... You can for instance arrange for a peer's DNS or NTP server UDP packets to pass, but generally block UDP on that interface as illegitimate.
I wonder why you seem to use firewalls inside your internal network to do this (i.e. with firewalls running on each host in the internal network)? Why don't you do this with a firewall at the borderline of your internal network (i.e. with a dedicated firewall machine that protects your whole internal network)? If a malicious user is inside your internal network neither explicit IP address requirements nor subnetting nor blocking what goes into your internal network helps. Therefore I still think that if the protection at the borderline fails you are basically doomed. As far as I understand what we are talking about, the issue is about opening ports for services which are used in a trusted network on firewalls which run on hosts in the trusted network. We do not talk about if it makes sense to have a firewall at the borderline of the trusted network. But - as far as I understand it - we talk about if it makes sense to have a firewall running on hosts in a trusted network. Furthermore it seems we talk about what is meant with "trusted".
From my point of view "trusted" means: http://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings
A trusted network means that you trust all users who can access this network. ------------------------------------------------------------------ If something else is meant with "trusted", (e.g. a network where childs install arbitrary software or where arbitrary guests can connect their personal computers or a university network where arbitrary students try to find out who is "the greatest hacker") then such a network is not a trusted network from my point of view. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 3 August 2011 13:03, Johannes Meixner <jsmeix@suse.de> wrote:
I wonder why you seem to use firewalls inside your internal network to do this (i.e. with firewalls running on each host in the internal network)?
Why don't you do this with a firewall at the borderline of your internal network (i.e. with a dedicated firewall machine that protects your whole internal network)?
If a malicious user is inside your internal network neither explicit IP address requirements nor subnetting nor blocking what goes into your internal network helps.
The problem seems to be you are thinking of "firewall", whereas I answered a question about why you may want to filter packets or restrict access to services, in what is meant to be a "trusted" network. If you are in a large corporate network, then other people in other departments may be in charge of the corporate Internet "firewall", you cannot "balkanise" physically and branch offices require connection to services; because the infrastructure is shared for cost, flexibility & practical reasons. Modems may be less common now, but such was a possibility for subverting a corporate firewall, perhaps VPN's are more common now a days. The "trusted" vs "external" is as I think I said before too black & white and fails in real world situations, where not every employee is impeccable and departments can have conflicts of interest. For example one department may be spun off and sold to commercial rival of another part of the corporation. Furthermore one department may minimise disruption, whereas another that's open and poorly administered may be completely compromised. These are things I have personally experienced, it's the real world. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello There seems to be unresolvable statuses on all live cd builds [1] openSUSE:Factory:Live > Status Monitor Will it get fixed ? The latest live cd [2] seem to be dated 07-Aug-2011 Thanks Glenn [1]https://build.opensuse.org/project/monitor?commit=Filter%3A&failed=1&unresolvable=1&broken=1&locked=1&pkgname=&repo_images=1&repo_snapshot=1&repo_standard=1&arch_i586=1&arch_x86_64=1&project=openSUSE%3AFactory%3ALive&defaults=0 [2]http://download.opensuse.org/factory/iso/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Monday, August 08, 2011 04:35:22 PM doiggl@velocitynet.com.au wrote:
Hello There seems to be unresolvable statuses on all live cd builds [1] ....
Wrong thread Glenn :) Changing topic (subject line) will not change "In-Reply-To:" field based on "Message-ID: " of previous message, which are parts of message header that is used by mail programs and in regular workflow is not editable by users. The result is that KMail, and any other client programs that support threading, will include your email in a thread: "opensuse-factory] Integration of firewalld?" instead to open a new thread. What to do? We have answer to this and few other useful things, collected in a wiki article: http://en.opensuse.org/openSUSE:Mailing_list_netiquette Questions, comments, or ideas how to improve mail list workflow, can be discussed on opensuse-project mail list. The same for wiki article is welcome on its discussion page: http://en.opensuse.org/openSUSE_talk:Mailing_list_netiquette -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On Aug 1 16:42 Frederic Crozat wrote (excerpt):
We have several locations in Yast which states "you might need to lower / punch firewall for this autodetection to work".
I don't know the details but from my point of view each such location could be a security bug in YaST. I assume it depends on how excactly it is implemented whether or not YaST suggests (or even urges) that the user should remove his current protection.
It would be better for an usuability PoV for Yast to talk to the firewall and punch it just for the autodetection.
From my point of view usability should not mean "just remove whatever
Punch the firewall is in almost any case wrong except you really want to set up a public accessible service. protection to make it just work". In contrast usability should mean to guide the user towards a reasonable setup. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday, August 02, 2011 01:28:00 AM Johannes Meixner wrote:
Hello,
On Aug 1 16:42 Frederic Crozat wrote (excerpt):
We have several locations in Yast which states "you might need to lower / punch firewall for this autodetection to work".
I don't know the details but from my point of view each such location could be a security bug in YaST. I assume it depends on how excactly it is implemented whether or not YaST suggests (or even urges) that the user should remove his current protection.
It would be better for an usuability PoV for Yast to talk to the firewall and punch it just for the autodetection.
Punch the firewall is in almost any case wrong except you really want to set up a public accessible service.
From my point of view usability should not mean "just remove whatever protection to make it just work". In contrast usability should mean to guide the user towards a reasonable setup.
Kind Regards Johannes Meixner IF we were talking Windows I would agree. But considering how unlikely it is to have malicious software on a machine running openSUSE, punching may not be a bad idea. Or make it need the password before opening up. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Monday, August 01, 2011 08:00:44 AM Ludwig Nussel wrote:
It would be better to switch to a trusted zone that allows e.g. printing in the first place instead.
Trusted zone is equivalent of no firewall at all, and nowadays there is no completely trusted zone. Internet browsers can be knocked down and that computer is no more trusted although it is behind NAT router working as expected. Completely lowering hands with a firewall offering no protection is just giving more opportunities to intruder. So, I vote of selective opening of ports, just as needed. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On Aug 2 08:30 Rajko M. wrote (excerpt):
I vote of selective opening of ports, just as needed.
Repeating the plain statement again and again does not help. I really wish someone would describe where there is security when opening ports "as needed" in a firewall. Of course there are particular cases where opening a particular port makes sense but in general opening ports make the firewall useless. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 03/08/2011 09:15, Johannes Meixner a écrit :
Of course there are particular cases where opening a particular port makes sense but in general opening ports make the firewall useless.
I fear not to understand this. A port opening break security only if the daemon listening have bugs, isn't it? Almost any server have the ssh port open, if not how can you manage it? so opening a port lower the security, yes, but do not make it null. Of course, the more ports openned, the more daemon have to be trusted and can have bugs. The problem of "trusted" networks in home or small company network is childs and guests. Most of the time the network is really to be trusted, but childs may accidentally break the security (installing trojan) or hack for fun. Guests may also come home with cracked computers and ask for connection. But all this is not common nor a 24/24 7/7 risk. So if child's computer is shut off and you have no guest, the network is safe. But stopping the firewall mean also forgetting to restart it... Stopping it on one port, with warning, once in a while, dont seems so frightening jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On Aug 3 09:27 jdd wrote (excerpt):
Le 03/08/2011 09:15, Johannes Meixner a écrit :
Of course there are particular cases where opening a particular port makes sense but in general opening ports make the firewall useless.
A port opening break security only if the daemon listening have bugs, isn't it?
Exactly. And opening a daemon's port makes the firewall useless for this daemon and you must rely on that this daemon has no bugs.
The problem of "trusted" networks in home or small company network is childs and guests.
Most of the time the network is really to be trusted, but childs may accidentally break the security (installing trojan) or hack for fun.
Guests may also come home with cracked computers and ask for connection.
When you let childs and guests in your trusted network, you must trust the childs and guests. If you do not trust the childs and guests, you must not let them in your trusted network. If childs are installing trojans or when guests connect cracked computers in your trusted network, you are doomed. Therefore you must separate your trusted network from the rest of your network and no longer let such childs and guests in your trusted network. http://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings --------------------------------------------------------------------- A trusted network means that you trust all users who can access this network. A user who can connect a computer to a network (e.g. a laptop where the user can work as "root") can send and receive any network traffic. Such a user can eavesdrop on the network and he can also fake any server machine in the network (except additional network switch hardware with an appropriate setup limits the user's network access). ... your trusted internal network traffic must be separated from the other non-trusted network traffic. The best way to get different kind of network traffic separated is when different networks are used. The simplest and most secure solution to maintain separated networks is when separated network hardware is used. ... The basic idea to increase likelihood that your network security is doomed is to mix up trusted and non-trusted network traffic in one same network environment. Save money and use the same network hardware for trusted and non-trusted network traffic and as a consequence pay with an increased likelihood that your network security is doomed --------------------------------------------------------------------- Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
Le 03/08/2011 09:55, Johannes Meixner a écrit :
And opening a daemon's port makes the firewall useless for this daemon and you must rely on that this daemon has no bugs.
yes
If childs are installing trojans or when guests connect cracked computers in your trusted network, you are doomed.
that's a reason to have a firewall in every computer :-)
Therefore you must separate your trusted network from the rest of your network and no longer let such childs and guests in your trusted network.
this is not always (often) possible. We have to share the printer, for example, to come back to the thread object. It's also why I prefere to have a network printer than a printer connected to my own computer (that would need me to open my computer to others). But it's a risk more easily managed. As I said, I don't have so many guests, and childs computers are not always up. by the way is there any SuSEfirewall2 log analizer that could help know is some attacks are made and what kind. the logs themselve are pretty intimidating - and hard to find on my desktop. could it be possible to have a log dispatcher and log reader in the YaST firewall module (may be open an other discussion?) thanks jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On Aug 3 10:14 jdd wrote (excerpt):
Le 03/08/2011 09:55, Johannes Meixner a écrit :
And opening a daemon's port makes the firewall useless for this daemon and you must rely on that this daemon has no bugs.
yes
This is what I liked to point out all the time.
If childs are installing trojans or when guests connect cracked computers in your trusted network, you are doomed.
that's a reason to have a firewall in every computer :-)
Of course "to be on the safe side you should not switch off the firewall".
Therefore you must separate your trusted network from the rest of your network and no longer let such childs and guests in your trusted network.
this is not always (often) possible. We have to share the printer, for example, to come back to the thread object.
When non-trusted users should be able to use your printing service you may have the CUPS server in the non-trusted network. When you need trusted printing, you cannot let non-trusted users also access your printing service. This means you would have to buy a second printer. Of course for a home network this is probably overkill. Usually you set up something wich provides reasonable security for your particular environment. But for a company network, it should not matter to pay the price for a separated printer for the separated network for guests.
It's also why I prefere to have a network printer
In this case you rely on that the services which run on your network printer have no bugs. Have in mind that nowadays network printers run several web-services like a HTTP server, often a FTP server, often several other services too. If a malicious user can compromise the services which run in your network printer or if a malicious user can even replace the whole software which is in your network printer (e.g. via firmware upload), you have a full network capable device in your internal network which can be remote controlled by the malicious user. When a device looks like a printer, acts like a printer, and sounds like a printer, that device could be a computer. You may Google for "network printer security risk". Happy frightening! ;-) Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
On Wednesday, August 03, 2011 02:15:05 AM Johannes Meixner wrote:
Hello,
On Aug 2 08:30 Rajko M. wrote (excerpt):
I vote of selective opening of ports, just as needed.
Repeating the plain statement again and again does not help.
Not that I understand how above relates to my post :) The fact is that about security policy we can only vote. Some users want bunker, some open street, majority something in between. I don't see how we can reconcile all opinions without voting about features that we want and we don't.
I really wish someone would describe where there is security when opening ports "as needed" in a firewall.
We already open ports when browsing the web, so few more for printing, or Samba shares, will not make big difference in security, but it will have huge impact on usability and marketability of openSUSE. Besides, construction firewalls (elements that prevent fast spreading of a fire) have doors that are closed when something activates fire alarm. So far I know we don't have such mechanism in place when something unexpected happens, like when some IP start port scan, or uses brute force to crack in the system. There are applications that do that, but that is not openSUSE default.
Of course there are particular cases where opening a particular port makes sense but in general opening ports make the firewall useless.
That tells exactly what initial Vincent's mail tells. :) No one wants that anything can tell firewall to open the gate, but certain application should be able to do that after user is asked and transaction is authorized. Of course question like: "Do you want to open port 80?" is completely useless. How many know what that 80 is used for; which will lead to random yes and no answers and complains that browser is not working. Not everyone has time to dive in documentation about networking and network security. Question has to be in terms that everybody can understand, like: "Do you want to allow Firefox to access Internet." which will: 1) increase number of correct answers and as consequence 2) increase user satisfaction (marketing bonus) 3) improve security (firewall is actually used, and you know who is using it) 4) minimize impact on support services Also, it will prevent alternative reactions to inability to solve problems where only culprit is firewall, like abandoning openSUSE and/or Linux. Judging by personal recollection on often asked questions in support channels, and some statistics about numbers of active vs. passive computer users, we lose hundreds of users weekly, only on this issue.
Kind Regards Johannes Meixner
-- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On Aug 3 22:34 Rajko M. wrote (excerpt):
On Wednesday, August 03, 2011 02:15:05 AM Johannes Meixner wrote: ...
I really wish someone would describe where there is security when opening ports "as needed" in a firewall.
We already open ports when browsing the web
Aarrgghh! Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On Aug 1 14:18 Vincent Untz wrote (excerpt):
For instance, when configuring printers, the tool can open the mdns, ipp, ipp-client and samba-client ports for 5 minutes and probe the network (ports will get closed after the 5 minutes). And if the user chooses to use a printer using one of those ports, the tool will permanently open the port.
What is the security concept behind this? In other words: Why is it secure to remove security for 5 minutes? Why is it secure to remove security permanently for particular stuff? The above are not meant as rhetorical questions. I am really interested in a security concept behind such cases. For information what I have in mind, please read http://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le mardi 02 août 2011, à 10:16 +0200, Johannes Meixner a écrit :
Hello,
On Aug 1 14:18 Vincent Untz wrote (excerpt):
For instance, when configuring printers, the tool can open the mdns, ipp, ipp-client and samba-client ports for 5 minutes and probe the network (ports will get closed after the 5 minutes). And if the user chooses to use a printer using one of those ports, the tool will permanently open the port.
What is the security concept behind this?
In other words: Why is it secure to remove security for 5 minutes? Why is it secure to remove security permanently for particular stuff?
Oh, it's certainly not the most secure approach; it's a compromise between user-friendliness and security. A few ways it could be made more secure include: - instead of having a 5 minutes timeout, just revert to previous state at the end of the probing - instead of blindly opening the service, open it only when on a specific network and for a specific server And while I haven't thought about firewall security in a while, the first example I come with when talking about trusted zones is connecting to WiFi at a university. Is this trusted or not? It might need to be trusted to allow printing documents and most people would trust it, and yet there are hundreds of individuals on this network, including some who might abuse your trust. My question is really: do we plan to integrate firewalld, or something similar, that would improve user-friendliness? This "something similar" could be based on zones -- even if I don't believe it's a better approach, at least, for users, it's an improvement compared to what we have today. I'd just like us to have a solution in the near future (12.1 if we can have fast action, 12.2 otherwise). Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On Aug 2 10:59 Vincent Untz wrote (excerpt):
Le mardi 02 août 2011, à 10:16 +0200, Johannes Meixner a écrit :
On Aug 1 14:18 Vincent Untz wrote (excerpt):
For instance, when configuring printers, the tool can open the mdns, ipp, ipp-client and samba-client ports for 5 minutes and probe the network (ports will get closed after the 5 minutes). And if the user chooses to use a printer using one of those ports, the tool will permanently open the port.
What is the security concept behind this?
In other words: Why is it secure to remove security for 5 minutes? Why is it secure to remove security permanently for particular stuff?
Oh, it's certainly not the most secure approach; it's a compromise between user-friendliness and security.
From my experience I think the only user-friendly way to deal with security settings is to talk to the user so that he knows what is going on. In particular when security should be removed, I think that an explicite confirmation by the user is mandatory.
From my personal point of view it would be perfectly o.k. if there is a popup dialog which shows:
"FancyStuff" requires that others have full access to your host via network. To make "FancyStuff" work, do you want that all network access protection will be removed now from your host? [Remove all protection] [Cancel (keeps current protection)] ---------------------------------------------------------------
And while I haven't thought about firewall security in a while, the first example I come with when talking about trusted zones is connecting to WiFi at a university. Is this trusted or not? It might need to be trusted to allow printing documents and most people would trust it, and yet there are hundreds of individuals on this network, including some who might abuse your trust.
Regarding firewall zones, you may have a look at https://bugzilla.novell.com/show_bug.cgi?id=630750 "the whole 'firewall zones stuff' has no meaning to normal users" FYI regarding printing: To print documents on a remote printer, there is no need to open any port in the firewall on your host. But when you like to get the user-friendly "CUPS browsing information" from CUPS servers in the network, the firewall on your host must permit that others (which are not necessarily CUPS servers) can send you stuff which looks like "CUPS browsing information" but then you must trust the others, see "print job phishing" in http://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings Alternatively use "BrowsePoll" to poll the information from explicite CUPS servers which you trust, see also https://bugzilla.novell.com/show_bug.cgi?id=433047#c12 When others in the network should be able to print documents via a CUPS server running on your host, the firewall on your host must permit that others can access your CUPS server. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
Le mardi 02 août 2011, à 11:38 +0200, Johannes Meixner a écrit :
Hello,
On Aug 2 10:59 Vincent Untz wrote (excerpt):
Le mardi 02 août 2011, à 10:16 +0200, Johannes Meixner a écrit :
In other words: Why is it secure to remove security for 5 minutes? Why is it secure to remove security permanently for particular stuff?
Oh, it's certainly not the most secure approach; it's a compromise between user-friendliness and security.
From my experience I think the only user-friendly way to deal with security settings is to talk to the user so that he knows what is going on. In particular when security should be removed, I think that an explicite confirmation by the user is mandatory.
Of course, the user would need to confirm this. And my understanding is that firewalld does this, thanks to PolicyKit. I'm not asking for ways to open the firewall without any interaction :-) (and again, just to be really clear, I'm not asking for firewalld itself to be integrated, but for something working in a similar way) [...]
To print documents on a remote printer, there is no need to open any port in the firewall on your host.
Just wondering: is this true for smb printers too? Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Vincent Untz wrote:
[...]
To print documents on a remote printer, there is no need to open any port in the firewall on your host.
Just wondering: is this true for smb printers too?
For one-shot browsing and name resolution with smb stuff you need to at least activate the 'samba-client' firewall config which loads an extra conntrack module. I don't know if there's a back channel needed when submitting a print job though. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Vincent Untz wrote:
And while I haven't thought about firewall security in a while, the first example I come with when talking about trusted zones is connecting to WiFi at a university. Is this trusted or not? It might need to be trusted to allow printing documents and most people would trust it, and yet there are hundreds of individuals on this network, including some who might abuse your trust.
What are you trying to protect against by running a firewall anyways? We always had the policy not run "unneeded" services by default. So cups and avahi are the only ones left. Both will hopefully be (local) socket activated in the future so they are only started if a local process actually requires their service, ie no ports open to the world by default at all anymore then.
My question is really: do we plan to integrate firewalld, or something similar, that would improve user-friendliness? This "something similar" could be based on zones -- even if I don't believe it's a better approach, at least, for users, it's an improvement compared to what we have today. I'd just like us to have a solution in the near future (12.1 if we can have fast action, 12.2 otherwise).
I don't know who 'we' refers to. I for one don't have plans to reimplement SuSEfirewall2 as DBus service. I also don't think that a dumbed down packet filter for the desktop gains us anything except for update problems (btdt). What I've read about firewalld so far isn't rocket science though and some features could be implemented on top of SuSEfirewall2 if really needed. The firewalld author also seems to think in the direction of a zone model similar to SuSEfirewall2 the hooks he needs in NM would serve SuSEfirewall2 (or rather fwzs on top of it) too. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On Aug 2 13:17 Ludwig Nussel wrote (excerpt):
What are you trying to protect against by running a firewall anyways? We always had the policy not run "unneeded" services by default. So cups and avahi are the only ones left. Both will hopefully be (local) socket activated in the future so they are only started if a local process actually requires their service, ie no ports open to the world by default at all anymore then.
By default cupsd is only accessible via the internal interface of the local host (lo) to accept print jobs via TCP port 631. Additionally by default cupsd is accessible via UDP port 631 to get "CUPS browsing information" from any remote host. If you like to receive "CUPS browsing information" you need a listening (i.e. running) cupsd on your local host which accepts "CUPS browsing information" from the remote host plus a firewall on your local host which permits incomming packages at UDP port 631. With socket activation, you may not receive "CUPS browsing information" unless the cupsd would also be activated if a package arrives at UDP port 631. But then I wonder if there is really better security because any malicious host could then send a package to UDP port 631 to get the cupsd activated there and afterwards send malicious "CUPS browsing information" to do "print job phishing". Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Johannes Meixner wrote:
On Aug 2 13:17 Ludwig Nussel wrote (excerpt):
What are you trying to protect against by running a firewall anyways? We always had the policy not run "unneeded" services by default. So cups and avahi are the only ones left. Both will hopefully be (local) socket activated in the future so they are only started if a local process actually requires their service, ie no ports open to the world by default at all anymore then.
By default cupsd is only accessible via the internal interface of the local host (lo) to accept print jobs via TCP port 631.
Additionally by default cupsd is accessible via UDP port 631 to get "CUPS browsing information" from any remote host.
If you like to receive "CUPS browsing information" you need a listening (i.e. running) cupsd on your local host which accepts "CUPS browsing information" from the remote host plus a firewall on your local host which permits incomming packages at UDP port 631.
With socket activation, you may not receive "CUPS browsing information" unless the cupsd would also be activated if a package arrives at UDP port 631.
But then I wonder if there is really better security because any malicious host could then send a package to UDP port 631 to get the cupsd activated there and afterwards send malicious "CUPS browsing information" to do "print job phishing".
I don't think starting up cups when receiving a broadcast packet on port 631 makes sense. That wouldn't be any improvement at all of course. Default socket activation should only trigger on local sockets for cups IMO. It's your package though so that's in your hands. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (11)
-
doiggl＠velocitynet.com.au -
Frederic Crozat -
jdd -
Johannes Meixner -
Ken Schneider - openSUSE -
Lars Müller -
Ludwig Nussel -
Rajko M. -
Rob Davies -
Roger Luedecke -
Vincent Untz