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

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

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 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 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 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

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

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

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 SUSE -- 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

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

On 2 August 2011 13:21, Johannes Meixner 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

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

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 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 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

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

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

Hello, On Aug 3 11:19 Rob Davies wrote (excerpt):

On 3 August 2011 08:31, Johannes Meixner 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

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

On 3 August 2011 13:03, Johannes Meixner 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