Just a thought here ... Have a look at the yast setup for xinetd and go this route, when thinking of the UI It would be so nice to have something similar for the setup of SuSEfirewall2 Johan 2006/6/30, Ludwig Nussel :

On Friday 30 June 2006 09:32, Lukas Ocilka wrote:

...

Well, having these services well-defined by packages themselves seems to be a good idea, on the other hand too many defined services might make the UI almost unusable :)

The listbox becomes shorter as it would only contain what's actually installed and a default install doesn't include most of the stuff that's currently offered.

cu Ludwig

-- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lukas Ocilka wrote:

Actually, yast2-firewall has been proposed to be used by common users. With some [Advanced] configuration for advanced users (or Server settings).

Xinetd configuration is a bit different and it's not suitable for common users. From my point of view, it's one badly-arranged table of settings.

Firewall configuration is set of more features divided into smaller dialogs. Considering the fact, that firewall plays with the security of the system, it should be as simple as possible and there should be listed as few entries as possible. That's why the firewall has also the Summary screen before saving the configuration.

Right, and what would help is: - - only list services/ports for servers (and sometimes clients) that are actually installed, because the service/port definitions are provided by RPMs (e.g. no HTTP/HTTPS if apache2 is not installed) - - provide a description of the service/ports you would open up Now that the idea has sparked some fire... I can see a few spots that should be thought of, as potential issues. Let's fuel some thoughts to it ;) 1) Conflicts ============ How to handle if, say, I have both apache2 and lighttpd installed at the same time ? Of course, the user will have to change listen ports anyway, because both HTTP daemons would conflict for system resources in the first place. But, say, I put apache on 80 and 443, and lighttpd on 8080. To me, that means a few things: The definition files in /etc/sysconfig/SuSEfirewall2.d/ (or wherever) must be named after the *package*, not the service. For the example above, we'd have, in that directory: apache2.xml lighttpd.xml Also, we might need "port groups", because one package could listen/require several ports or port ranges, that can be turned on or off individually. For apache2, that would be HTTP (80) and HTTPS (443). For tomcat, that would be 8080, 8081 and the various control ports. The apache2.xml file could look something like this: - ---8<------------------------------------------------------------ <susefirewall2-service id="apache"> <summary lang="en">Web server</summary> <summary lang="fr">Serveur Web</summary> <description lang="en"> Authorize access to websites hosted on this server, through Apache2. </description> ... <port-group id="http"> <port proto="tcp" port="80" /> <description lang="en"> Authorize access to the standard, non-encrypted HTTP port. </description> </port-group> <port-group id="https"> <port proto="tcp" port="443" /> <description lang="en"> Authorize access to the encrypted and secure HTTPS port. </description> </port-group> </susefirewall2-service> - ---8<------------------------------------------------------------ So, how to handle conflicts ? I think it should be done in the UI: if the end-user enables both 80 for apache and then tries to enable 80 for lighttpd, the UI should refuse to do so and provide an informative message on why that is not possible. Or it could just pop up a warning/information message that the port 80 is already open for apache2, because for SuSEfirewall2, in the end, it just means: ALLOW on TCP port 80, whatever the daemon is. But then one must be careful when the end-user chooses to close down "HTTP for Apache2", because it might still end up being open because he has also enabled "HTTP for lighttpd". So.. it's not *that* easy ;) 2) Port changes =============== A more experienced user might want to change the port some service is listening on. As of the example above, he could change the lighttpd configuration to listen on 8080 instead of 80. The problem is that the lighttpd.xml file for the firewall is static, and hence still contains "80" instead of "8080" for the TCP port. The only option I see atm would be to also ship some scripts that validate the firewall config files (e.g. lighttpd.xml) against the configuration of the daemon. That must also be provided by the package, because each piece of software uses different formats and tags for configuration. This is when it becomes a bit tricky. A less perfect but simpler, and hence better option could also be to give the admin the possibility of overriding the ports for a given "service" (e.g. lighttpd or apache2) in the firewall config UI. There are too many cases you couldn't catch with the first approach (use an alternative config file, or just think of the apache2 config: it's so versatile and complex that the port that is actually used could be hidden almost anywhere (in vhosts.d/* or a conf.d/*)). So maybe it's just better to let the more experienced user handle that himself. 3) Extensible (by the user/admin) ================================= Similar to above, consider apache2: if someone adds several vhosts that listen on different ports (e.g. 8080, 10000, 11000)... So there must still be some option to add ports yourself. It would be even nicer if they could be associated with the "apache2" config for the firewall. That way, in the firewall config screen, the admin could just say: disable apache2 (and all the ports that are associated with it, including for his own vhosts). Maybe a collapsable tree-like UI would be appropriate: [-] lighttpd (summary, description) [ ] HTTP (80) [ ] HTTPS (443) [x] 8080 (added by user) [x] apache2 (summary, descr.) [x] HTTP (80) [x] HTTPS (443) [x] 10000 (added by user) [ ] jabberd (summary, descr) [ ] XMPP (5222) [ ] XMPP/SSL (5223) etc... That's probably easy enough for beginners and still flexible enough for experts. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEpPrEr3NMWliFcXcRAuCCAJ9RWVdye3d2PelRp/PzVa97V+Q0+wCgiGAM iSofHvJdpeiAK4rE5e5S0Uc= =SAqi -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org

Beg me pardon If I jump in the middle of a thread, But the subject lend me to a reflexion. You must very thoroughsly define in the firewall UI the different net segments, what is not done at present time. You must distinguish clearly: * the external net (=Internet or the hardware router if any) * the DMZ if any * the local(s) net (private adresses) * __the local machine__ the problem is important because for Iptable the local machine is a special one and in most small networks this very same machine is not only the gateway, but also the server Let me state that in "normal" network organisation the web, ftp, mail server should go on the DMZ. In that case they are identified by they interface name. But many DSL users now have a gateway/router/server... and little net expertise. In fact it's for _these_ people that the Firewall configuration must be the better designed (the experienced users can make themselves the iptables instructions). So, define your vocabulary and explain... For example, configuring postfix is extremely difficult because the domain name is undefined. You have a local net domain name (private IP) may be (or may be not) a public domain name (dodin.org, for me) and don't know what is the gateway name... what is the "hostname" of the gateway? You are probably not aware of these problems (I beg they are not problems for you :-), but for me they are and I manage a server for several years now :-( thanks jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org