hi folks, Am a great fan of shorewall for its shear usability. But always felts it lacks a great UI to manage it. I was discussing with tom on a possible UI to manage the system better. Has anyone working on that (other than webmin) ?? - sree -- http://picasaweb.google.com/gnuyoga All things come through desire and every sincere prayer is answered ! ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> hi folks, > > Am a great fan of shorewall for its shear usability. But always felts it > lacks a great UI to manage it. I was discussing with tom on a possible > UI to manage the system better. Has anyone working on that (other than > webmin) ?? >Dear Sree, May I make a few suggestions on UI features I''d like to see, if you do implement it? * A GUI is often used by people who don''t understand what the shorewall terms mean. So good diagrams, and plenty of help is essential. It needs to cater for people who haven''t used shorewall before (and are probably moving up from something more basic like firestarter or drakfw) * Once the FW is configured, a link to an external test site would be useful. Eg Gibson''s "Shields Up" is a useful confirmation that the FW really is working correctly. (Could shorewall.net provide this service?) * The GUI and CLI must co-exist. Most importantly, when the GUI makes a small change, it must not mess up the layout of a carefully written and commented configuration file. (So many tools do this wrong!!) * Once configured, it would be really neat to see a diagram showing how the FW is set up. * Integration with other tools, eg port-scanning one''s own machine to see which services are already running; links to log files (eg ssh login failures), wireshark, nmap,... * Support for some common-case profiles/templates. I''d like to see at least these: - The machine is the house''s primary router: it should also run dhcpd, and do NAT. [firestarter does this one extremely well, as does drakgw] - The machine is a standalone laptop. It may have many interfaces, eg firewire, wifi, ppp, not all of which are connected at the time the shorewall UI is run. All of them must be protected. If I subsequently add a new physical device (eg PCMCIA card, or a USB-network device), then the shorewall defaults must apply to it. I know this is hard to do, but it''s also *important*. GUI users generally expect not to have to re-run the GUI except when they change their policy(*); this means that shorewall needs to be able to handle devices that didn''t even exist at the time when the system was booted, and shorewall was started. [The MS Windows firewall has a nice option here, i.e. to firewall off any and all devices, routing over whichever one is currently connected] - The machine is a laptop, and the hotel is overcharging for the wifi. The laptop should use wlan0 to connect to the hotel''s expensive access point by WEP/WPA etc. The laptop should also act as an access point, sharing the connection with other members of one''s family (eg hostap + dhcpd + nat). The same wireless card must probably handle both roles. - etc... * Loading and Saving existing setups so that the system can easily be switched between them. I hope some of the above is useful. Best wishes, Richard ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
richard, ur input is a good start for me. i was thinking of a very rich internet application and what u said is achievable. let me host the project and get started ! I will create the milestone for this month. i would be very happy to have some like you in the advisory board. anyone aware of some good hosting server for this project (project management/svn/etc) ? i know assembla.com but that''s paid. is code.google.com good ? - sree On Fri, Nov 28, 2008 at 8:53 PM, Richard Neill <rn214@cam.ac.uk> wrote:> > hi folks, > > > > Am a great fan of shorewall for its shear usability. But always felts it > > lacks a great UI to manage it. I was discussing with tom on a possible > > UI to manage the system better. Has anyone working on that (other than > > webmin) ?? > > > > Dear Sree, > > May I make a few suggestions on UI features I''d like to see, if you do > implement it? > > * A GUI is often used by people who don''t understand what the > shorewall terms mean. So good diagrams, and plenty of help is essential. > It needs to cater for people who haven''t used shorewall before (and are > probably moving up from something more basic like firestarter or drakfw) > > * Once the FW is configured, a link to an external test site would be > useful. Eg Gibson''s "Shields Up" is a useful confirmation that the FW > really is working correctly. (Could shorewall.net provide this service?) > > * The GUI and CLI must co-exist. Most importantly, when the GUI makes > a small change, it must not mess up the layout of a carefully written > and commented configuration file. (So many tools do this wrong!!) > > * Once configured, it would be really neat to see a diagram showing > how the FW is set up. > > * Integration with other tools, eg port-scanning one''s own machine to > see which services are already running; links to log files (eg ssh login > failures), wireshark, nmap,... > > * Support for some common-case profiles/templates. I''d like to see at > least these: > > - The machine is the house''s primary router: it should also run > dhcpd, and do NAT. [firestarter does this one extremely well, as does > drakgw] > > - The machine is a standalone laptop. It may have many interfaces, > eg firewire, wifi, ppp, not all of which are connected at the time the > shorewall UI is run. All of them must be protected. If I subsequently > add a new physical device (eg PCMCIA card, or a USB-network device), > then the shorewall defaults must apply to it. > I know this is hard to do, but it''s also *important*. > GUI users generally expect not to have to re-run the GUI except when > they change their policy(*); this means that shorewall needs to be able > to handle devices that didn''t even exist at the time when the system was > booted, and shorewall was started. > [The MS Windows firewall has a nice option here, i.e. to firewall off > any and all devices, routing over whichever one is currently connected] > > - The machine is a laptop, and the hotel is overcharging for the wifi. > The laptop should use wlan0 to connect to the hotel''s expensive access > point by WEP/WPA etc. The laptop should also act as an access point, > sharing the connection with other members of one''s family (eg hostap + > dhcpd + nat). The same wireless card must probably handle both roles. > > - etc... > > > * Loading and Saving existing setups so that the system can easily be > switched between them. > > > I hope some of the above is useful. > > Best wishes, > > Richard > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer''s > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Shorewall-devel mailing list > Shorewall-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-devel >-- http://picasaweb.google.com/gnuyoga All things come through desire and every sincere prayer is answered ! ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
(श्री) Sreekanth B wrote:> richard, > > ur input is a good start for me. i was thinking of a very rich internet > application and what u said is achievable. let me host the project and > get started ! I will create the milestone for this month. > > i would be very happy to have some like you in the advisory board. > > anyone aware of some good hosting server for this project (project > management/svn/etc) ? i know assembla.com <http://assembla.com> but > that''s paid. is code.google.com <http://code.google.com> good ?The Shorewall project itself uses sourceforge.net. -Tom -- Tom Eastep \ The ultimate result of shielding men from the Shoreline, \ effects of folly is to fill the world with fools. Washington, USA \ -Herbert Spencer http://shorewall.net \________________________________________________ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Richard Neill wrote:> > May I make a few suggestions on UI features I''d like to see, if you do > implement it?This post raises many of the issues that have kept me from trying to build a GUI for Shorewall myself (aside from my lack of GUI design experience). Please don''t interpret this post to mean that I''m against having a Shorewall GUI; I think that an up-to-date and easy-to-use GUI would be a great addition to Shorewall. I''m rather trying to set expectations about the scope of the project and to point out problems that are likely to arise. Shorewall grew out of my experience with Seawall. Seawall was intended to be a "Firewall for Dummies" and although it didn''t have a GUI, it had very definite assumptions about what firewall/gateway problems it could solve and what problems that it couldn''t solve. What I found was that there was a need for a more sophisticated tool that could be used by experienced network administrators; I designed Shorewall with those users in mind. So from day one, Shorewall has not been intended as the firewall for the masses and I personally expect that users will have a level of networking knowledge appropriate for the types of things that they attempt to do with Shorewall. That expectation isn''t always met, of course, and the resulting gap (chasm) between people''s knowledge and their aspirations keeps us busy answering support requests. One of the biggest problems with Seawall was that it only supported three basic configurations: standalone, two-interface and three-interface. This "N sizes fit all" limitation turned out to be a killer.> > * A GUI is often used by people who don''t understand what the > shorewall terms mean.Be honest -- they are often used by people who couldn''t distinguish "MAC address" from "Ogg Vorbis". Any time that I read a support request that begins "I''m new to Shorewall and Linux...", I mentally translate that phrase to "I haven''t a clue how IP networking works..."; that translation almost always proves to be accurate.> So good diagrams, and plenty of help is essential. > It needs to cater for people who haven''t used shorewall before (and are > probably moving up from something more basic like firestarter or drakfw)So one has to ask why these users need to "move up"; probably because of the "N sizes fit all" assumptions of the solution that they are currently using?> > * Once the FW is configured, a link to an external test site would be > useful. Eg Gibson''s "Shields Up" is a useful confirmation that the FW > really is working correctly.Not really. I consider "Shields Up" to be a front to lure users into buying Gibson products. (Could shorewall.net provide this service?) No, for both technical and practical reasons. The entire idea presumes that there is a "correct" behavior of a firewall and that all other behaviors are "incorrect". In reality what is "correct" in one user''s case may be completely broken for another user. Again, one size does not fit all. And shorewall.net has very meager network, computer and development resources which make such a service impossible to create and support.> > * The GUI and CLI must co-exist. Most importantly, when the GUI makes > a small change, it must not mess up the layout of a carefully written > and commented configuration file. (So many tools do this wrong!!)That''s because it is hard. For the class of users that you are targeting, I don''t think that it is really a requirement but it may be a requirement for current Shorewall users migrating to the GUI.> > * Once configured, it would be really neat to see a diagram showing > how the FW is set up.But definitely not a "must have"> > * Integration with other tools, eg port-scanning one''s own machine to > see which services are already running; links to log files (eg ssh login > failures), wireshark, nmap,...What I think you are really describing here is a firewall appliance GUI, not a Shorewall GUI.> > * Support for some common-case profiles/templates. I''d like to see at > least these:So 3 sizes fit all. Because of the lack of networking sophistication of your target user, if the problem to be solved isn''t one of those covered by a template, then your target user is immediately lost and the task of helping them out of the wilderness falls on Shorewall support. At one point, we had parameter-driven templates for Shorewall -- that experiment was short-lived. People would use the appropriate template but the instant that they needed to do something not covered by the template, they were completely lost because of the paradigm shift required to use Shorewall''s native capabilities. I took the stance that it was important for the user to learn *something* about Shorewall native capabilities when they first configured their firewall and we eliminated the templates. So the transition from using the template to doing more sophisticated things must be made as seamless as possible. I think that is the hardest problem to solve in this project.> > - The machine is the house''s primary router: it should also run > dhcpd, and do NAT. [firestarter does this one extremely well, as does > drakgw]So why not just use these products if they fit? The Shorewall home page makes a point of recommending against using Shorewall if one of these easy-to-use tools fits your needs.> > - The machine is a standalone laptop. It may have many interfaces, > eg firewire, wifi, ppp, not all of which are connected at the time the > shorewall UI is run. All of them must be protected. If I subsequently > add a new physical device (eg PCMCIA card, or a USB-network device), > then the shorewall defaults must apply to it. > I know this is hard to do, but it''s also *important*. > GUI users generally expect not to have to re-run the GUI except when > they change their policy(*); this means that shorewall needs to be able > to handle devices that didn''t even exist at the time when the system was > booted, and shorewall was started.Shorewall could provide the ability to configure the treatment of traffic that doesn''t match any of the defined zones (the current code simply applies the appropriate POLICY to such traffic).> [The MS Windows firewall has a nice option here, i.e. to firewall off > any and all devices, routing over whichever one is currently connected] > > - The machine is a laptop, and the hotel is overcharging for the wifi. > The laptop should use wlan0 to connect to the hotel''s expensive access > point by WEP/WPA etc. The laptop should also act as an access point, > sharing the connection with other members of one''s family (eg hostap + > dhcpd + nat). The same wireless card must probably handle both roles.The firewall should also make coffee and cook breakfast for the family and make the beds and... Again, more than just a Shorewall GUI is being described; Sree, be sure that the scope of the project is well understood up front. -Tom -- Tom Eastep \ The ultimate result of shielding men from the Shoreline, \ effects of folly is to fill the world with fools. Washington, USA \ -Herbert Spencer http://shorewall.net \________________________________________________ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
On Fri, Nov 28, 2008 at 11:05:58AM -0800, Tom Eastep wrote:> This post raises many of the issues that have kept me from trying to > build a GUI for Shorewall myself (aside from my lack of GUI design > experience). > > Please don''t interpret this post to mean that I''m against having a > Shorewall GUI; I think that an up-to-date and easy-to-use GUI would be a > great addition to Shorewall. I''m rather trying to set expectations > about the scope of the project and to point out problems that are likely > to arise.Certainly anyone that thinks a GUI makes things easier is completely wrong. A GUI just presents things differently, but the same actual knowledge and understanding is required to do the job. You may not have to remember exact syntax, but you still have to understand the meaning. Sure it can help you by giving lists of interfaces and options, but you must understand them to make use of that. We happen to use webmin to configure shorewall where I work, because it was partially implemented already and we had already decided to use webmin for everything else, so it works, but we make no claims about it being easy to configure a firewall with it, just possible. It does help to avoid syntax errors to some extent (but far from perfect of course).> Shorewall grew out of my experience with Seawall. Seawall was intended > to be a "Firewall for Dummies" and although it didn''t have a GUI, it had > very definite assumptions about what firewall/gateway problems it could > solve and what problems that it couldn''t solve. What I found was that > there was a need for a more sophisticated tool that could be used by > experienced network administrators; I designed Shorewall with those > users in mind.Well it has turned out quite well so far.> So from day one, Shorewall has not been intended as the firewall for the > masses and I personally expect that users will have a level of > networking knowledge appropriate for the types of things that they > attempt to do with Shorewall. That expectation isn''t always met, of > course, and the resulting gap (chasm) between people''s knowledge and > their aspirations keeps us busy answering support requests. > > One of the biggest problems with Seawall was that it only supported > three basic configurations: standalone, two-interface and > three-interface. This "N sizes fit all" limitation turned out to be a > killer.That sounds quite limiting.> Be honest -- they are often used by people who couldn''t distinguish "MAC > address" from "Ogg Vorbis". Any time that I read a support request that > begins "I''m new to Shorewall and Linux...", I mentally translate that > phrase to "I haven''t a clue how IP networking works..."; that > translation almost always proves to be accurate.In which case they don''t understand enough to actually create firewall rules that will do the job no matter what the GUI does.> So one has to ask why these users need to "move up"; probably because of > the "N sizes fit all" assumptions of the solution that they are > currently using?Certainly a GUI that could show diagrams that somehow explain the current rules might be possible and might even be useful, but it sure would be hard to do.> Not really. I consider "Shields Up" to be a front to lure users into > buying Gibson products. > > (Could shorewall.net provide this service?)How can one even do a test. If you have some software using a specific protocol, then short of using it, you can''t really test to make sure it works.> No, for both technical and practical reasons. The entire idea presumes > that there is a "correct" behavior of a firewall and that all other > behaviors are "incorrect". In reality what is "correct" in one user''s > case may be completely broken for another user. Again, one size does not > fit all. > > And shorewall.net has very meager network, computer and development > resources which make such a service impossible to create and support. > > That''s because it is hard. For the class of users that you are > targeting, I don''t think that it is really a requirement but it may be a > requirement for current Shorewall users migrating to the GUI.Some users like things to use a specific type of whitespace, others like things alligned a certain way. If the GUI could guess what the user liked, I would be very impressed.> > * Once configured, it would be really neat to see a diagram showing > > how the FW is set up. > > But definitely not a "must have"And what would it look like?> So 3 sizes fit all. Because of the lack of networking sophistication of > your target user, if the problem to be solved isn''t one of those covered > by a template, then your target user is immediately lost and the task of > helping them out of the wilderness falls on Shorewall support. > > At one point, we had parameter-driven templates for Shorewall -- that > experiment was short-lived. People would use the appropriate template > but the instant that they needed to do something not covered by the > template, they were completely lost because of the paradigm shift > required to use Shorewall''s native capabilities. I took the stance that > it was important for the user to learn *something* about Shorewall > native capabilities when they first configured their firewall and we > eliminated the templates. > > So the transition from using the template to doing more sophisticated > things must be made as seamless as possible. I think that is the hardest > problem to solve in this project.Probably simplest to start out learning to do it right from the start.> Shorewall could provide the ability to configure the treatment of > traffic that doesn''t match any of the defined zones (the current code > simply applies the appropriate POLICY to such traffic).I like it. It''s simple and easy to understand. Policy is applied unless rules say otherwise.> > [The MS Windows firewall has a nice option here, i.e. to firewall off > > any and all devices, routing over whichever one is currently connected] > > > > - The machine is a laptop, and the hotel is overcharging for the wifi. > > The laptop should use wlan0 to connect to the hotel''s expensive access > > point by WEP/WPA etc. The laptop should also act as an access point, > > sharing the connection with other members of one''s family (eg hostap + > > dhcpd + nat). The same wireless card must probably handle both roles. > > The firewall should also make coffee and cook breakfast for the family > and make the beds and... > > Again, more than just a Shorewall GUI is being described; Sree, be sure > that the scope of the project is well understood up front.I find windows firewalls tend to always work at the application level, not the system level, and they ask users questions that the user doesn''t have a clue how to answer in the first place. What good is that? They also never seem to be stateful the way iptables is. -- Len Sorensen ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Lennart Sorensen wrote:> Certainly anyone that thinks a GUI makes things easier is completely > wrong.I think that depends on what the GUI tries to do. Often GUI ''Wizards'' make getting started a lot easier than using the native capabilities of the package.> Sure it can help you by giving lists of interfaces and options, but you > must understand them to make use of that.Task-oriented wizards can also be of help.> > We happen to use webmin to configure shorewall where I work, because it > was partially implemented already and we had already decided to use > webmin for everything else, so it works, but we make no claims about it > being easy to configure a firewall with it, just possible. It does help > to avoid syntax errors to some extent (but far from perfect of course).I think that it is dangerous to judge all GUIs by Webmin. Webmin makes little or no attempt to add any subsystem knowledge to the GUI.> >> Shorewall grew out of my experience with Seawall. > > Well it has turned out quite well so far.Thanks.> > Certainly a GUI that could show diagrams that somehow explain the > current rules might be possible and might even be useful, but it sure > would be hard to do.I agree.>> So the transition from using the template to doing more sophisticated >> things must be made as seamless as possible. I think that is the hardest >> problem to solve in this project. > > Probably simplest to start out learning to do it right from the start. > >> Shorewall could provide the ability to configure the treatment of >> traffic that doesn''t match any of the defined zones (the current code >> simply applies the appropriate POLICY to such traffic). > > I like it. It''s simple and easy to understand. Policy is applied > unless rules say otherwise.But neither rules nor policies can currently be defined for uncatagorized traffic (that traffic where either the source or destination is not in a defined zone). I think it would be useful to be able to define such rules. -Tom -- Tom Eastep \ The ultimate result of shielding men from the Shoreline, \ effects of folly is to fill the world with fools. Washington, USA \ -Herbert Spencer http://shorewall.net \________________________________________________ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
wow its nice c lot of different perspectives. i have hosted the project in code.google.com http://code.google.com/p/shorewall-ui - sree On Sat, Nov 29, 2008 at 6:40 AM, Tom Eastep <teastep@shorewall.net> wrote:> Lennart Sorensen wrote: > > > Certainly anyone that thinks a GUI makes things easier is completely > > wrong. > > I think that depends on what the GUI tries to do. Often GUI ''Wizards'' > make getting started a lot easier than using the native capabilities of > the package. > > > Sure it can help you by giving lists of interfaces and options, but you > > must understand them to make use of that. > > Task-oriented wizards can also be of help. > > > > > We happen to use webmin to configure shorewall where I work, because it > > was partially implemented already and we had already decided to use > > webmin for everything else, so it works, but we make no claims about it > > being easy to configure a firewall with it, just possible. It does help > > to avoid syntax errors to some extent (but far from perfect of course). > > I think that it is dangerous to judge all GUIs by Webmin. Webmin makes > little or no attempt to add any subsystem knowledge to the GUI. > > > > >> Shorewall grew out of my experience with Seawall. > > > > Well it has turned out quite well so far. > > Thanks. > > > > > Certainly a GUI that could show diagrams that somehow explain the > > current rules might be possible and might even be useful, but it sure > > would be hard to do. > > I agree. > > >> So the transition from using the template to doing more sophisticated > >> things must be made as seamless as possible. I think that is the hardest > >> problem to solve in this project. > > > > Probably simplest to start out learning to do it right from the start. > > > >> Shorewall could provide the ability to configure the treatment of > >> traffic that doesn''t match any of the defined zones (the current code > >> simply applies the appropriate POLICY to such traffic). > > > > I like it. It''s simple and easy to understand. Policy is applied > > unless rules say otherwise. > > But neither rules nor policies can currently be defined for > uncatagorized traffic (that traffic where either the source or > destination is not in a defined zone). I think it would be useful to be > able to define such rules. > > -Tom > -- > Tom Eastep \ The ultimate result of shielding men from the > Shoreline, \ effects of folly is to fill the world with fools. > Washington, USA \ -Herbert Spencer > http://shorewall.net \________________________________________________ > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer''s > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Shorewall-devel mailing list > Shorewall-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-devel > >-- http://picasaweb.google.com/gnuyoga All things come through desire and every sincere prayer is answered ! ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Dear All, Here are a few more thoughts, and some replies to others. Firstly, something I forgot to mention: the Mandriva firewall GUI tools (drakfw and drakgw) are actually perl/GTK-based frontends to shorewall. So, I might recommend them as a good place to start.> > One of the biggest problems with Seawall was that it only supported > three basic configurations: standalone, two-interface and > three-interface. This "N sizes fit all" limitation turned out to be a > killer. > >> * A GUI is often used by people who don''t understand what the >> shorewall terms mean. > > Be honest -- they are often used by people who couldn''t distinguish "MAC > address" from "Ogg Vorbis". Any time that I read a support request that > begins "I''m new to Shorewall and Linux...", I mentally translate that > phrase to "I haven''t a clue how IP networking works..."; that > translation almost always proves to be accurate. > >> So good diagrams, and plenty of help is essential. >> It needs to cater for people who haven''t used shorewall before (and are >> probably moving up from something more basic like firestarter or drakfw) > > So one has to ask why these users need to "move up"; probably because of > the "N sizes fit all" assumptions of the solution that they are > currently using? >I think there''s something to be said for learning a powerful tool in a beginners'' mode from the outset. If you start out using firestarter, and then need to move to shorewall to have one extra feature that fs doesn''t have, it means quite a lot of effort to learn a new tool, and then port across your rules.>> * Once the FW is configured, a link to an external test site would be >> useful. Eg Gibson''s "Shields Up" is a useful confirmation that the FW >> really is working correctly. > > Not really. I consider "Shields Up" to be a front to lure users into > buying Gibson products.I agree - it''s especially a nuisance that there''s no way to directly link to the shields-up URL. There are other services that are less "lure-like". However, the shields-up service is actually quite good when you finally get there. (There are some other sites that provide similar services too).> > (Could shorewall.net provide this service?) > > No, for both technical and practical reasons. The entire idea presumes > that there is a "correct" behavior of a firewall and that all other > behaviors are "incorrect". In reality what is "correct" in one user''s > case may be completely broken for another user. Again, one size does not > fit all.I understand. However, it''s very hard for a user to test his own firewall without access to another machine somewhere else. It''s also very hard to observe that a firewall is correctly configured. So, as a "giving-the-user-some-more-confidence-in-his-setup" measure, I think some external component is very useful. Just because one can''t cover every case doesn''t mean we shouldn''t cover the common case :-)> > And shorewall.net has very meager network, computer and development > resources which make such a service impossible to create and support. > >> * The GUI and CLI must co-exist. Most importantly, when the GUI makes >> a small change, it must not mess up the layout of a carefully written >> and commented configuration file. (So many tools do this wrong!!) > > That''s because it is hard. For the class of users that you are > targeting, I don''t think that it is really a requirement but it may be a > requirement for current Shorewall users migrating to the GUI.I still claim this is essential. For an example, consider /etc/fstab. I quite frequently used to have to edit this by hand, and would leave it sensibly formatted, with comments, whitespace etc so I could refer back to it later. Many tools just trashed this - instead of merely adding or editing the single line that was necessary. The GUI tool destroyed all my comments. Personally, I have configured shorewall stuff by hand, but I''m not a great expert at so doing. I frequently have to refer to the (excellent) docs if there''s something advanced I want to do. If there were a GUI, I''d try that, before resorting to the docs. But I''d really be upset if the GUI mangled my hand-edited config files in an unnecessarily destructive way. In other words, many GUI users will want to switch between the GUI and the CLI. If you do target beginners only, and don''t want to implement the smart behaviour required, please at least back up the old config files, and warn the user.> >> * Once configured, it would be really neat to see a diagram showing >> how the FW is set up. > > But definitely not a "must have" > >> * Integration with other tools, eg port-scanning one''s own machine to >> see which services are already running; links to log files (eg ssh login >> failures), wireshark, nmap,... > > What I think you are really describing here is a firewall appliance GUI, > not a Shorewall GUI.True - though perhaps they are almost the same! I think that nmap-ing one''s own machine is a useful way for a wizard to guess which ports should be opened (or even to hint that certain ports must be closed!).> >> * Support for some common-case profiles/templates. I''d like to see at >> least these: > > So 3 sizes fit all. Because of the lack of networking sophistication of > your target user, if the problem to be solved isn''t one of those covered > by a template, then your target user is immediately lost and the task of > helping them out of the wilderness falls on Shorewall support.Sorry - that wasn''t my meaning. I listed 3 I could think of, that I personally would use. But I imagine that there would be 50 examples. Why are examples/templates/profiles useful? Because starting with a blank sheet is very hard for a novice. Consider trying a new piece of software you''ve never used before; for a concrete example, let''s consider the "Hydrogen" drum synth. When first opened, it looks really bewildering. It''s hard to explore the UI because you haven''t got any actual content to play with, so most of the features do nothing. However, as it happens, the hydrogen authors worked this out, and allow you to open a demo (File->Open Demo). Now all the UI elements actually do something, and it''s much easier to explore.> > At one point, we had parameter-driven templates for Shorewall -- that > experiment was short-lived. People would use the appropriate template > but the instant that they needed to do something not covered by the > template, they were completely lost because of the paradigm shift > required to use Shorewall''s native capabilities. I took the stance that > it was important for the user to learn *something* about Shorewall > native capabilities when they first configured their firewall and we > eliminated the templates. > > So the transition from using the template to doing more sophisticated > things must be made as seamless as possible. I think that is the hardest > problem to solve in this project.That''s very interesting - I agree.> >> - The machine is the house''s primary router: it should also run >> dhcpd, and do NAT. [firestarter does this one extremely well, as does >> drakgw] > > So why not just use these products if they fit? The Shorewall home page > makes a point of recommending against using Shorewall if one of these > easy-to-use tools fits your needs.Well the nice thing is that drakfw/drakgw give me a reasonably good initial setup for shorewall. However I know that once I''ve used the GUI to do initial setup for that machine, I must make all future edits by hand, and must never re-run the GUI.> >> - The machine is a standalone laptop. It may have many interfaces, >> eg firewire, wifi, ppp, not all of which are connected at the time the >> shorewall UI is run. All of them must be protected. If I subsequently >> add a new physical device (eg PCMCIA card, or a USB-network device), >> then the shorewall defaults must apply to it. >> I know this is hard to do, but it''s also *important*. >> GUI users generally expect not to have to re-run the GUI except when >> they change their policy(*); this means that shorewall needs to be able >> to handle devices that didn''t even exist at the time when the system was >> booted, and shorewall was started. > > Shorewall could provide the ability to configure the treatment of > traffic that doesn''t match any of the defined zones (the current code > simply applies the appropriate POLICY to such traffic).Sorry, I wasn''t clear. What I mean is that shorewall should set the default ZONE for an INTERFACE that doesn''t (yet) exist. - eg the interface is physically not present when shorewall is configured, or is not present when shorewall is started (eg wireless lan rfkill switch), or the interface device exists, but it isn''t up, and has no assigned IP address.> >> [The MS Windows firewall has a nice option here, i.e. to firewall off >> any and all devices, routing over whichever one is currently connected] >> >> - The machine is a laptop, and the hotel is overcharging for the wifi. >> The laptop should use wlan0 to connect to the hotel''s expensive access >> point by WEP/WPA etc. The laptop should also act as an access point, >> sharing the connection with other members of one''s family (eg hostap + >> dhcpd + nat). The same wireless card must probably handle both roles. > > The firewall should also make coffee and cook breakfast for the family > and make the beds and...:-) OK - that last one is rather a wishlist item. But a GUI that doesn''t facilitate some of the clever stuff might actually be better implemented as a tutorial. One more thought: may I suggest that the GUI should provide a log explaining what it is doing? This helps the user to learn that, say "clicking the ALLOW_PING button" actually corresponds to adding the rule: ACCEPT net fw icmp 8 - to the file: /etc/shorewall/rules Best wishes, Richard ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Richard Neill wrote:> > I think there''s something to be said for learning a powerful tool in a > beginners'' mode from the outset. If you start out using firestarter, and > then need to move to shorewall to have one extra feature that fs doesn''t > have, it means quite a lot of effort to learn a new tool, and then port > across your rules.I suppose that it is worth noting that Shorwall has a lot of features *because* it doesn''t have a GUI; adding features is cheaper with a text-based tool like Shorewall.> > I understand. However, it''s very hard for a user to test his own > firewall without access to another machine somewhere else. It''s also > very hard to observe that a firewall is correctly configured. So, as a > "giving-the-user-some-more-confidence-in-his-setup" measure, I think > some external component is very useful. Just because one can''t cover > every case doesn''t mean we shouldn''t cover the common case :-)If you want to create such a site, I''ll be more than happy to add links to it from shorewall.net :-)> > Why are examples/templates/profiles useful? Because starting with a > blank sheet is very hard for a novice. Consider trying a new piece of > software you''ve never used before; for a concrete example, let''s > consider the "Hydrogen" drum synth. When first opened, it looks really > bewildering. It''s hard to explore the UI because you haven''t got any > actual content to play with, so most of the features do nothing. > However, as it happens, the hydrogen authors worked this out, and allow > you to open a demo (File->Open Demo). Now all the UI elements actually > do something, and it''s much easier to explore.I wasn''t disagreeing with the notion of examples/templates/profiles; I just wanted to make the point that a paradigm shift should not be necessary when moving from them to the native configuration facilities.>> Shorewall could provide the ability to configure the treatment of >> traffic that doesn''t match any of the defined zones (the current code >> simply applies the appropriate POLICY to such traffic). > > Sorry, I wasn''t clear. What I mean is that shorewall should set the > default ZONE for an INTERFACE that doesn''t (yet) exist. > > - eg the interface is physically not present when shorewall is > configured, or is not present when shorewall is started (eg wireless lan > rfkill switch), or the interface device exists, but it isn''t up, and has > no assigned IP address. >Shorewall-perl 4.2.3 will allow ''+'' as an interface name in /etc/shorewall/interfaces. That name will match any interface. -Tom -- Tom Eastep \ The ultimate result of shielding men from the Shoreline, \ effects of folly is to fill the world with fools. Washington, USA \ -Herbert Spencer http://shorewall.net \________________________________________________ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Tom Eastep wrote:> ... >> Why are examples/templates/profiles useful? Because starting with a >> blank sheet is very hard for a novice. Consider trying a new piece of >> software you''ve never used before; for a concrete example, let''s >> consider the "Hydrogen" drum synth. When first opened, it looks really >> bewildering. It''s hard to explore the UI because you haven''t got any >> actual content to play with, so most of the features do nothing. >> However, as it happens, the hydrogen authors worked this out, and allow >> you to open a demo (File->Open Demo). Now all the UI elements actually >> do something, and it''s much easier to explore. > > I wasn''t disagreeing with the notion of examples/templates/profiles; I > just wanted to make the point that a paradigm shift should not be > necessary when moving from them to the native configuration facilities.I would add that it would be good if the existing quickstart guide templates were used as the basis of demos/examples. Paul ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Tom Eastep wrote:> > If you want to create such a site, I''ll be more than happy to add links > to it from shorewall.net :-) >Of course you are right: coding beats emailing any day. However, it seems rather needless, given that there are other sites already. I spent some time googling to see what there is, and tested a few of the friendly-probing sites; I conclude that, although ShieldsUp tends to have some annoyances, it does actually seem to be the best tool out there.>> - eg the interface is physically not present when shorewall is >> configured, or is not present when shorewall is started (eg wireless lan >> rfkill switch), or the interface device exists, but it isn''t up, and has >> no assigned IP address. >> > > Shorewall-perl 4.2.3 will allow ''+'' as an interface name in > /etc/shorewall/interfaces. That name will match any interface. >Thank you, I didn''t know that. Richard ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Richard Neill wrote:> > Tom Eastep wrote:>> Shorewall-perl 4.2.3 will allow ''+'' as an interface name in >> /etc/shorewall/interfaces. That name will match any interface. >> > > Thank you, I didn''t know that.I just implemented it yesterday based on this discussion :-) -Tom -- Tom Eastep \ The ultimate result of shielding men from the effects of Shoreline, \ folly is to fill the world with fools. Washington, USA \ -- Herbert Spencer ------------------------------------------------------------------------ http://www.shorewall.net ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/