[opensuse-factory] Idea for SuSEfirewall2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just a little idea I stumbled upon... How about having a directory that allows dropping in files as part of packages (e.g. /etc/sysconfig/SuSEfirewall2.d/). Those files could include stuff like - - a detailed description of the ports that are relevant to the package - - parsable data for SuSEfirewall2, to be able to open (or close) ports based on that information - ---8< XMPP/Jabber Open these ports to allow communication with an XMPP/Jabber server hosted in your network. - ---8< (of course, it should be capable of being localized) Those ports could then show up in "Allowed Services" and "Masquerading". Currently, SuSEfirewall2 has a fixed set of "well-known" (not in a sense of /etc/services) ports it can put names on (HTTP, SSH, rsync). But those ports don't include a description, that could be really valuable for beginners. Also, SuSEfirewall2 doesn't provide names for other ports, that are not in that fixed set, e.g. for gnutella, jabber/xmpp, ... and you have to go through [Advanced...] A system like above could be useful, to include port definitions for SuSEfirewall2 as part of RPM packages (e.g. jabberd). Well, just an idea, off the top of my head. What do you guys think, would it be useful ? feasible ? Post/discuss on another list ? cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> _\_v The more things change, the more they stay insane. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEpMeKr3NMWliFcXcRAuKDAJ9BLw5rhYnyuThfMVNaq9rus2Y5xwCgjp6I kVZmPXpltue+du3rGYGKnfA= =jqFo -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-factory] Idea for SuSEfirewall2
> Just a little idea I stumbled upon... > > How about having a directory that allows dropping in files as part of > packages (e.g. /etc/sysconfig/SuSEfirewall2.d/). > > Those files could include stuff like > - a detailed description of the ports that are relevant to the package > - parsable data for SuSEfirewall2, to be able to open (or close) ports > based on that information > ---8< > > XMPP/Jabber > > Open these ports to allow communication with an > XMPP/Jabber server hosted in your network. > > > > > > > ---8< > (of course, it should be capable of being localized) > I'd like to have that too :-) It's nothing SuSEfirewall2 should deal > with though. The YaST firewall module can make use of that > information instead. Currently the information about ports is > hardcoded in /usr/share/YaST2/modules/SuSEFirewallServices.ycp Hi, I like the proposal, that's almost exactly what I wanted to do. Additionally, using an XML format for storing this kind of information is even better than I planned. The only thing, I doubt, is the translation of and but there definitely must be a way to do that somehow. Also the /path/ for storing these XML files has to be consulted with some LSB guru to follow the LSB standards (if such rule exists). 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 :) Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Idea for SuSEfirewall2
On Friday 30 June 2006 08:41, Pascal Bleser wrote: > Just a little idea I stumbled upon... > > How about having a directory that allows dropping in files as part of > packages (e.g. /etc/sysconfig/SuSEfirewall2.d/). > > Those files could include stuff like > - a detailed description of the ports that are relevant to the package > - parsable data for SuSEfirewall2, to be able to open (or close) ports > based on that information > ---8< > > XMPP/Jabber > > Open these ports to allow communication with an > XMPP/Jabber server hosted in your network. > > > > > > > ---8< > (of course, it should be capable of being localized) I'd like to have that too :-) It's nothing SuSEfirewall2 should deal with though. The YaST firewall module can make use of that information instead. Currently the information about ports is hardcoded in /usr/share/YaST2/modules/SuSEFirewallServices.ycp cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Idea for SuSEfirewall2
Op vrijdag 30 juni 2006 08:41, schreef Pascal Bleser: > XMPP/Jabber > > Open these ports to allow communication with an > XMPP/Jabber server hosted in your network. > > > > > > > ---8< > (of course, it should be capable of being localized) Perhaps with: XMPP/Jabber Open these ports to allow communication with an XMPP/Jabber server hosted in your network. -- Richard Bos Without a home the journey is endless - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Idea for SuSEfirewall2
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Idea for SuSEfirewall2
2006/6/30, Pascal Bleser <[EMAIL PROTECTED]>: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just a little idea I stumbled upon... How about having a directory that allows dropping in files as part of packages (e.g. /etc/sysconfig/SuSEfirewall2.d/). Those files could include stuff like - - a detailed description of the ports that are relevant to the package - - parsable data for SuSEfirewall2, to be able to open (or close) ports based on that information - ---8< XMPP/Jabber Open these ports to allow communication with an XMPP/Jabber server hosted in your network. - ---8< (of course, it should be capable of being localized) Those ports could then show up in "Allowed Services" and "Masquerading". Currently, SuSEfirewall2 has a fixed set of "well-known" (not in a sense of /etc/services) ports it can put names on (HTTP, SSH, rsync). But those ports don't include a description, that could be really valuable for beginners. Also, SuSEfirewall2 doesn't provide names for other ports, that are not in that fixed set, e.g. for gnutella, jabber/xmpp, ... and you have to go through [Advanced...] A system like above could be useful, to include port definitions for SuSEfirewall2 as part of RPM packages (e.g. jabberd). Well, just an idea, off the top of my head. What do you guys think, would it be useful ? feasible ? Post/discuss on another list ? I agree on everything you say. SuSEfirewall2 and yast-interface to same could really benefit from this. Johan
Re: [opensuse-factory] Idea for SuSEfirewall2
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 <[EMAIL PROTECTED]>: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Idea for SuSEfirewall2
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. Lukas Johan N. wrote: > 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 <[EMAIL PROTECTED]>: >> >> 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Idea for SuSEfirewall2
With the feedback seen, I suggest we evaluate this for 10.2. could you add it to the feature wishlist? I've added it already to our internal feature tool so that we can start evaluating ourselves, Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpHUwQSPRvsG.pgp Description: PGP signature
Re: [opensuse-factory] Idea for SuSEfirewall2
-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< Web server Serveur Web Authorize access to websites hosted on this server, through Apache2. ... Authorize access to the standard, non-encrypted HTTP port. Authorize access to the encrypted and secure HTTPS port. - ---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, 1, 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)
Re: [opensuse-factory] Idea for SuSEfirewall2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jaeger wrote: > With the feedback seen, I suggest we evaluate this for 10.2. could > you add it to the feature wishlist? I've added it already to our > internal feature tool so that we can start evaluating ourselves, Could someone else please take care of it and copy some of the stuff discussed here ? I'm off for holidays now and pretty much in a hurry. Maybe the discussion is worth a page on the wiki to collect ideas and potential issues, dunno... cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> _\_v The more things change, the more they stay insane. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEpPs5r3NMWliFcXcRAq3QAJwOuPKjyFZoeZ2bQLAinkYulfxMiwCfZZbK nR6S2m59gl4Hzlv9/pgELfw= =jbNi -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [opensuse-factory] Idea for SuSEfirewall2
One thing I would add is that yast, when it writes the .xml files, should ALWAYS include a nice commented block at the top explaining the possible entries so that if needed, one could hand edit the xml files using the information presented in the comments. Jonathon M. Robison Infrastructure Architect ET, ITI 313-323-9529 -Original Message- From: Richard Bos [mailto:[EMAIL PROTECTED] Sent: Friday, June 30, 2006 3:17 AM To: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] Idea for SuSEfirewall2 Op vrijdag 30 juni 2006 08:41, schreef Pascal Bleser: > XMPP/Jabber > > Open these ports to allow communication with an > XMPP/Jabber server hosted in your network. > > > > > > > ---8< > (of course, it should be capable of being localized) Perhaps with: XMPP/Jabber Open these ports to allow communication with an XMPP/Jabber server hosted in your network. -- Richard Bos Without a home the journey is endless - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Idea for SuSEfirewall2
Pascal Bleser wrote: > How about having a directory that allows dropping in files as part of > packages (e.g. /etc/sysconfig/SuSEfirewall2.d/). > ... > Those ports could then show up in "Allowed Services" and "Masquerading". If you masquerade a service, then the daemon package with the XML description will be installed on the target machine, not on the machine running the firewall. Otherwise, I like te idea too :) Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Idea for SuSEfirewall2
On Friday 30 June 2006 01:41, Pascal Bleser wrote: > Just a little idea I stumbled upon... > > How about having a directory that allows dropping in files as part of > packages (e.g. /etc/sysconfig/SuSEfirewall2.d/). Excellent ideas. > Those ports could then show up in "Allowed Services" and "Masquerading". > > Currently, SuSEfirewall2 has a fixed set of "well-known" (not in a sense > of /etc/services) ports it can put names on (HTTP, SSH, rsync). > But those ports don't include a description, that could be really > valuable for beginners. I'd like to see this tied into the YaST runlevel display also. Adding maybe an "FW" column that would indicate that a service can be exposed externally to a network and should be in a firewall rule for best practices. Also serves as another check & balance area for auditing. 0=internal only, non-networked, no need to firewall 1=can be exposed externally to a network, recommend to firewall 2=designed to be exposed externally to a network, must be firewalled 3=external, firewall disabled 4=external, firewall enabled 5=internal, firewall disabled 6= you get the idea . . . Provide some useful info for newbies to learn from and a refresher for the experts. > Also, SuSEfirewall2 doesn't provide names for other ports, that are not > in that fixed set, e.g. for gnutella, jabber/xmpp, ... and you have to > go through [Advanced...] > > A system like above could be useful, to include port definitions for > SuSEfirewall2 as part of RPM packages (e.g. jabberd). In the spec file have recommended/established port definitions for firewalling? Excellent idea. Even for FWBuilder and others... > Well, just an idea, off the top of my head. > What do you guys think, would it be useful ? feasible ? > Post/discuss on another list ? One of the most needed enhancements to SUSE Linux, open or enterprise. Thanks Pascal, Stan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Idea for SuSEfirewall2
Stan Glasoe wrote: > On Friday 30 June 2006 01:41, Pascal Bleser wrote: >> Just a little idea I stumbled upon... >> >> How about having a directory that allows dropping in files as part of >> packages (e.g. /etc/sysconfig/SuSEfirewall2.d/). > > Excellent ideas. So, who's gonna do that :)? Just kidding... I have had this in my TODO since last October or so and now it appears to be quite a big feature. On the other hand, it seems that more people would like to have it implemented so I'm gonna put my effort into it. Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Idea for SuSEfirewall2
2006/6/30, Lukas Ocilka <[EMAIL PROTECTED]>: 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 Everything you say as long as usability improves beyond current level :) One good windows example of this that comes to mind is visnetic firewall. Which also AFAIK I remember from my head has options for monitoring built in. Now combining the options to control speed/resources would be extremely welcome too as a part of a more complete solution. Angain just thoughts and ideas. I hope this makes sense Johan Summary screen before saving the configuration. Lukas Johan N. wrote: > 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 <[EMAIL PROTECTED]>: >> >> 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Idea for SuSEfirewall2
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
