Thread: [Fwbuilder-discussion] HTML dump
Brought to you by:
mikehorn
From: Frank W. <Fra...@ct...> - 2006-03-15 09:28:24
|
Hi all, I have spent some time editing the policy-html.xsl that was part of=20 fwbuilder1. For those who have never used it, this is an XSLT file that=20 generates html output from fwb files. I use this in my install script, so=20 that when I install a new policy, the HTML dump gets uploaded to a=20 (restricted) web site where remote admins can look in a human readable mann= er=20 at their policy. I have made the following enhancements:=20 *) reordered the output such that the (most interesting) firewall object co= mes=20 first *) added output of Address ranges, Object Groups, Services and Service Grou= ps *) placed lots of anchors and hyperlinks, so that clicking on an object nam= e=20 takes you to its definition in the file As this isn't included anymore in fwbuilder2, I don't know if anyone is=20 interested, or even if it could make it back into the package. If anyone is interested, I'll gladly post/mail the files and give further=20 info. Beware that I am not an XML/XSLT expert and that the code is probably= =20 not as neat/clean as it could be... Have a nice day =46rank =2D-=20 _______________________________________________ Centre de Technologie de l'Education 29 avenue John F. Kennedy L-1855 Luxembourg-Kirchberg t=E9l.: +352 478-5973 fax: +352 333797 _______________________________________________ |
From: Michael 'b. S. <msc...@gi...> - 2006-03-15 10:10:56
|
Good morning. I would love to take a look at it. :] Greetings, Michael On Wed, 15 Mar 2006 - 10:30am, Frank Weis wrote: >Hi all, > >I have spent some time editing the policy-html.xsl that was part of >fwbuilder1. For those who have never used it, this is an XSLT file that >generates html output from fwb files. I use this in my install script, so >that when I install a new policy, the HTML dump gets uploaded to a >(restricted) web site where remote admins can look in a human readable manner >at their policy. > >I have made the following enhancements: >*) reordered the output such that the (most interesting) firewall object comes >first >*) added output of Address ranges, Object Groups, Services and Service Groups >*) placed lots of anchors and hyperlinks, so that clicking on an object name >takes you to its definition in the file > >As this isn't included anymore in fwbuilder2, I don't know if anyone is >interested, or even if it could make it back into the package. > >If anyone is interested, I'll gladly post/mail the files and give further >info. Beware that I am not an XML/XSLT expert and that the code is probably >not as neat/clean as it could be... > >Have a nice day > >Frank > > -- I love deadlines, especially the sound they make as they go whooshing by. |
From: Frank W. <Fra...@ct...> - 2006-03-15 10:19:12
Attachments:
new-policy-html.xsl
|
Hi, here it comes. You also need fwbuilder.dtd, but that is part of the fwbuilder package. Use like this: xsltproc new-policy-html.xsl fwbuilder-file.fwb >htmldump.html Have fun, =46rank On Wednesday 15 March 2006 11:10, Michael 'buk' Scherer wrote: > Good morning. > > I would love to take a look at it. :] > > Greetings, > Michael > > On Wed, 15 Mar 2006 - 10:30am, Frank Weis wrote: > >Hi all, > > > >I have spent some time editing the policy-html.xsl that was part of > >fwbuilder1. For those who have never used it, this is an XSLT file that > >generates html output from fwb files. I use this in my install script, so > >that when I install a new policy, the HTML dump gets uploaded to a > >(restricted) web site where remote admins can look in a human readable > > manner at their policy. > > > >I have made the following enhancements: > >*) reordered the output such that the (most interesting) firewall object > > comes first > >*) added output of Address ranges, Object Groups, Services and Service > > Groups *) placed lots of anchors and hyperlinks, so that clicking on an > > object name takes you to its definition in the file > > > >As this isn't included anymore in fwbuilder2, I don't know if anyone is > >interested, or even if it could make it back into the package. > > > >If anyone is interested, I'll gladly post/mail the files and give further > >info. Beware that I am not an XML/XSLT expert and that the code is > > probably not as neat/clean as it could be... > > > >Have a nice day > > > >Frank =2D-=20 _______________________________________________ Centre de Technologie de l'Education 29 avenue John F. Kennedy L-1855 Luxembourg-Kirchberg t=E9l.: +352 478-5973 fax: +352 333797 _______________________________________________ |
From: ted c. <tcr...@ea...> - 2006-03-15 16:39:49
|
It should be posted. edc -----Original Message----- From: fwb...@li... [mailto:fwb...@li...] On Behalf Of = Frank Weis Sent: Wednesday, March 15, 2006 1:21 AM To: Michael 'buk' Scherer Cc: fwb...@li... Subject: Re: [Fwbuilder-discussion] HTML dump Hi, here it comes. You also need fwbuilder.dtd, but that is part of the fwbuilder package. Use like this: xsltproc new-policy-html.xsl fwbuilder-file.fwb >htmldump.html Have fun, Frank On Wednesday 15 March 2006 11:10, Michael 'buk' Scherer wrote: > Good morning. > > I would love to take a look at it. :] > > Greetings, > Michael > > On Wed, 15 Mar 2006 - 10:30am, Frank Weis wrote: > >Hi all, > > > >I have spent some time editing the policy-html.xsl that was part of > >fwbuilder1. For those who have never used it, this is an XSLT file = that > >generates html output from fwb files. I use this in my install = script, so > >that when I install a new policy, the HTML dump gets uploaded to a > >(restricted) web site where remote admins can look in a human = readable > > manner at their policy. > > > >I have made the following enhancements: > >*) reordered the output such that the (most interesting) firewall = object > > comes first > >*) added output of Address ranges, Object Groups, Services and = Service > > Groups *) placed lots of anchors and hyperlinks, so that clicking on = an > > object name takes you to its definition in the file > > > >As this isn't included anymore in fwbuilder2, I don't know if anyone = is > >interested, or even if it could make it back into the package. > > > >If anyone is interested, I'll gladly post/mail the files and give = further > >info. Beware that I am not an XML/XSLT expert and that the code is > > probably not as neat/clean as it could be... > > > >Have a nice day > > > >Frank --=20 _______________________________________________ Centre de Technologie de l'Education 29 avenue John F. Kennedy L-1855 Luxembourg-Kirchberg t=E9l.: +352 478-5973 fax: +352 333797 _______________________________________________ |
From: <va...@vk...> - 2006-03-15 16:51:41
|
On Mar 15, 2006, at 8:42 AM, ted creedon wrote: > It should be posted. > absolutely. What is the best way to do this ? I can upload the xslt script to =20 "scripts" section on Sourceforge. Frank, could you write a little =20 blurb about this script ? I would post it on the web site then. thanks! --vk > edc > > -----Original Message----- > From: fwb...@li... > [mailto:fwb...@li...] On Behalf =20= > Of Frank > Weis > Sent: Wednesday, March 15, 2006 1:21 AM > To: Michael 'buk' Scherer > Cc: fwb...@li... > Subject: Re: [Fwbuilder-discussion] HTML dump > > Hi, > > here it comes. > You also need fwbuilder.dtd, but that is part of the fwbuilder =20 > package. > > Use like this: > xsltproc new-policy-html.xsl fwbuilder-file.fwb >htmldump.html > > Have fun, > > Frank > On Wednesday 15 March 2006 11:10, Michael 'buk' Scherer wrote: >> Good morning. >> >> I would love to take a look at it. :] >> >> Greetings, >> Michael >> >> On Wed, 15 Mar 2006 - 10:30am, Frank Weis wrote: >>> Hi all, >>> >>> I have spent some time editing the policy-html.xsl that was part of >>> fwbuilder1. For those who have never used it, this is an XSLT =20 >>> file that >>> generates html output from fwb files. I use this in my install =20 >>> script, so >>> that when I install a new policy, the HTML dump gets uploaded to a >>> (restricted) web site where remote admins can look in a human =20 >>> readable >>> manner at their policy. >>> >>> I have made the following enhancements: >>> *) reordered the output such that the (most interesting) firewall =20= >>> object >>> comes first >>> *) added output of Address ranges, Object Groups, Services and =20 >>> Service >>> Groups *) placed lots of anchors and hyperlinks, so that clicking =20= >>> on an >>> object name takes you to its definition in the file >>> >>> As this isn't included anymore in fwbuilder2, I don't know if =20 >>> anyone is >>> interested, or even if it could make it back into the package. >>> >>> If anyone is interested, I'll gladly post/mail the files and give =20= >>> further >>> info. Beware that I am not an XML/XSLT expert and that the code is >>> probably not as neat/clean as it could be... >>> >>> Have a nice day >>> >>> Frank > > --=20 > _______________________________________________ > Centre de Technologie de l'Education > 29 avenue John F. Kennedy > L-1855 Luxembourg-Kirchberg > t=E9l.: +352 478-5973 > fax: +352 333797 > _______________________________________________ > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting =20 > language > that extends applications into web and mobile media. Attend the =20 > live webcast > and join the prime developer group breaking into this new coding =20 > territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642= > _______________________________________________ > Fwbuilder-discussion mailing list > Fwb...@li... > https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion > > > !DSPAM:4418437864714640380590! > |
From: <lu...@lu...> - 2006-03-19 11:07:53
|
On Wednesday, 2006-03-15 at 11:21:16 +0100, Frank Weis wrote: > here it comes. I've just converted the policy set for a customer, and I find this very useful. But the set is huge, making the HTML hard to navigate. I'm wondering, not having any experience with XSLT myself, if it would be possible to insert links that allow one to jump to the individual firewall rulesets, and inside them, to the rulesets of the interfaces, the NAT rules and the global ruleset. Thanks for publishing this! Lupe Christoph -- | You know we're sitting on four million pounds of fuel, one nuclear | | weapon and a thing that has 270,000 moving parts built by the lowest | | bidder. Makes you feel good, doesn't it? | | Rockhound in "Armageddon", 1998, about the Space Shuttle | |
From: Frank W. <Fra...@ct...> - 2006-03-20 15:19:16
|
On Sunday 19 March 2006 12:07, Lupe Christoph wrote: > On Wednesday, 2006-03-15 at 11:21:16 +0100, Frank Weis wrote: > > here it comes. > > I've just converted the policy set for a customer, and I find this very > useful. But the set is huge, making the HTML hard to navigate. I'm > wondering, not having any experience with XSLT myself, if it would be > possible to insert links that allow one to jump to the individual > firewall rulesets, and inside them, to the rulesets of the interfaces, > the NAT rules and the global ruleset. > > Thanks for publishing this! > Lupe Christoph Well, anything should be possible... If I understand you correctly, you hav= e=20 multiple firewall objects in one file, and you want to have one more level = of=20 indexing, maybe with one frame displaying the list of the firewalls, and=20 another displaying the actual data? We have one firewall per file, so this never bothered me... but I think it = can=20 be done. =46rank =2D-=20 _______________________________________________ Centre de Technologie de l'Education 29 avenue John F. Kennedy L-1855 Luxembourg-Kirchberg t=E9l.: +352 478-5973 fax: +352 333797 _______________________________________________ |
From: Lupe C. <lu...@lu...> - 2006-03-20 20:35:12
|
On Monday, 2006-03-20 at 16:23:19 +0100, Frank Weis wrote: > On Sunday 19 March 2006 12:07, Lupe Christoph wrote: > > I've just converted the policy set for a customer, and I find this very > > useful. But the set is huge, making the HTML hard to navigate. I'm > > wondering, not having any experience with XSLT myself, if it would be > > possible to insert links that allow one to jump to the individual > > firewall rulesets, and inside them, to the rulesets of the interfaces, > > the NAT rules and the global ruleset. > Well, anything should be possible... If I understand you correctly, you have > multiple firewall objects in one file, and you want to have one more level of > indexing, maybe with one frame displaying the list of the firewalls, and > another displaying the actual data? I'd like to have an index into the firewall objects, and inside those objects an index of the rulesets. > We have one firewall per file, so this never bothered me... but I think it can > be done. I maintain multiple firewalls for a customer that share quite a number of objects. Also my own firewalls are similarly related. But that customer has requested a copy of the rulesets for a while now, and very much likes the output generated with the help of your XSL file. So the main goal is accomplished :-). The indices would just be icing on the cake. I've always meant to learn XSLT, but right now I just don't have the time. If I did, this would be a nice learning project :-( Lupe Christoph -- | You know we're sitting on four million pounds of fuel, one nuclear | | weapon and a thing that has 270,000 moving parts built by the lowest | | bidder. Makes you feel good, doesn't it? | | Rockhound in "Armageddon", 1998, about the Space Shuttle | |
From: Erich T. <eri...@th...> - 2006-05-18 14:02:55
|
Hi everybody apologies if this is so obvious I cannot even find a reference to.... Until now I used the fwbuilder generated script to just set the iptables rules of my firewall. I did not bother about stopping the firewall, just deleted all rules and set the policies to ACCEPT. Assuming that the tick box to designate an interface as a management interface serrves a purpose I set out to explore how to use the firewall script to disable everything but the management access, alas without success. Would anyone please point me to a reference. Thanks Erich |
From: <va...@vk...> - 2006-05-18 15:54:55
|
On May 18, 2006, at 7:02 AM, Erich Titl wrote: > Hi everybody > > apologies if this is so obvious I cannot even find a reference to.... > > Until now I used the fwbuilder generated script to just set the > iptables rules of my firewall. I did not bother about stopping the > firewall, just deleted all rules and set the policies to ACCEPT. > > Assuming that the tick box to designate an interface as a management > interface serrves a purpose I set out to explore how to use the > firewall > script to disable everything but the management access, alas without > success. a policy with a single rule that denies everything should do that, or even just empty policy with no rules at all. You will also need to mark a checkbox in the firewall settings dialog to generate a rule to permit ssh access to the firewall from the management station --vk |
From: Erich T. <eri...@th...> - 2006-05-18 22:40:09
|
Hi Vadim Vadim Kurland =E2=9C=8D wrote: >=20 > .. >=20 >=20 > a policy with a single rule that denies everything should do that, or = > even just empty policy with no rules at all. You will also need to mar= k=20 > a checkbox in the firewall settings dialog to generate a rule to permi= t=20 > ssh access to the firewall from the management station This is obvious to me, the thing I was referring to is - without specifying a separate firewall set up there does not seem to=20 be a way to buckle down the firewall. IMHO setting a management=20 interface only makes sense for the shutdown scenario, not for normal=20 firewall operation. So basicaly this tick box only serves as a shortcut=20 to allow ssh access :-( I was wondering if there was a way to be able to run a command like firewall.fw --stop to shut down the firewall. Whichever action this would mean is philosophical by nature. Is a shut=20 down firewall open or closed by definition? My personal preference would = be 'lock everything up except for the management interfaces'. Anyway, this means I have to define 2 distinct firewall rulesets for=20 each firewall in fwb and distribute them differently scripted. There=20 might be place for improvement as such a scenario is error prone. Thanks Erich |
From: ted c. <tcr...@ea...> - 2006-05-19 14:00:19
|
How about --stop --deny and --stop --accept? tedc -----Original Message----- From: fwb...@li... [mailto:fwb...@li...] On Behalf Of = Erich Titl Sent: Thursday, May 18, 2006 3:40 PM To: Vadim Kurland ? Cc: fwb...@li... Subject: Re: [Fwbuilder-discussion] fwbuilder stop Hi Vadim Vadim Kurland ? wrote: >=20 > .. >=20 >=20 > a policy with a single rule that denies everything should do that, or = > even just empty policy with no rules at all. You will also need to = mark=20 > a checkbox in the firewall settings dialog to generate a rule to = permit=20 > ssh access to the firewall from the management station This is obvious to me, the thing I was referring to is - without specifying a separate firewall set up there does not seem to=20 be a way to buckle down the firewall. IMHO setting a management=20 interface only makes sense for the shutdown scenario, not for normal=20 firewall operation. So basicaly this tick box only serves as a shortcut=20 to allow ssh access :-( I was wondering if there was a way to be able to run a command like firewall.fw --stop to shut down the firewall. Whichever action this would mean is philosophical by nature. Is a shut=20 down firewall open or closed by definition? My personal preference would = be 'lock everything up except for the management interfaces'. Anyway, this means I have to define 2 distinct firewall rulesets for=20 each firewall in fwb and distribute them differently scripted. There=20 might be place for improvement as such a scenario is error prone. Thanks Erich ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, = security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=120709&bid&3057&dat=121642 _______________________________________________ Fwbuilder-discussion mailing list Fwb...@li... https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion |
From: ted c. <tcr...@ea...> - 2006-05-19 16:28:41
|
Vadim, Comments? tedc #!/bin/sh set -x #stop and clean up iptables --flush iptables --flush -t nat iptables --flush -t mangle iptables --zero iptables -L|g Chain|cut -d " " -f 2 > /tmp/foo for i in `cat /tmp/foo`;do iptables -X $i;done #rm /tmp/foo iptables -L #start iptables --policy INPUT ACCEPT iptables --policy OUTPUT ACCEPT iptables --policy FORWARD ACCEPT iptables -L > |
From: <va...@vk...> - 2006-05-19 17:00:59
|
On May 19, 2006, at 9:27 AM, ted creedon wrote: > Vadim, > > Comments? > > tedc > > #!/bin/sh > set -x > #stop and clean up > iptables --flush > iptables --flush -t nat > iptables --flush -t mangle > iptables --zero > > > iptables -L|g Chain|cut -d " " -f 2 > /tmp/foo > for i in `cat /tmp/foo`;do iptables -X $i;done > #rm /tmp/foo > iptables -L > > #start > iptables --policy INPUT ACCEPT > iptables --policy OUTPUT ACCEPT > iptables --policy FORWARD ACCEPT > iptables -L > this leaves firewall wide open, I am not sure this is what Erich wants. Erich says: > Whichever action this would mean is philosophical by nature. Is a > shut down firewall open or closed by definition? My personal > preference would be 'lock everything up except for the management > interfaces'. I agree with this definition, except I would permit connections _from_ addresses defined in firewall settings instead of _to_ management interface. We can tighten it even more and restrict both source and destination, but I am not sure this is necessary. Also, fwbuilder already generates a rule to permit ssh access from management addresses, so I do not have to generate any new rules to implement "stop" option. Command line options "start" and "stop" seem reasonable, I'll see what I can do. To reiterate, "stop" will turn all chains into blocking mode and only permit ssh access from management station or management network as defined in the firewall settings dialog; "start" will load the whole policy. Running script without command line option is equivalent to "start" to maintain backward compatibility. I know how to do this for iptables, but doing it for pf and ipf is going to be tricky. --vk |
From: ted c. <tcr...@ea...> - 2006-05-19 17:24:41
|
Yes, but it was meant to be a sample script. tedc -----Original Message----- From: fwb...@li... [mailto:fwb...@li...] On Behalf Of Vadim Kurland ? Sent: Friday, May 19, 2006 10:01 AM To: ted creedon Cc: fwb...@li... Subject: Re: [Fwbuilder-discussion] fwbuilder stop On May 19, 2006, at 9:27 AM, ted creedon wrote: > Vadim, > > Comments? > > tedc > > #!/bin/sh > set -x > #stop and clean up > iptables --flush > iptables --flush -t nat > iptables --flush -t mangle > iptables --zero > > > iptables -L|g Chain|cut -d " " -f 2 > /tmp/foo > for i in `cat /tmp/foo`;do iptables -X $i;done > #rm /tmp/foo > iptables -L > > #start > iptables --policy INPUT ACCEPT > iptables --policy OUTPUT ACCEPT > iptables --policy FORWARD ACCEPT > iptables -L > this leaves firewall wide open, I am not sure this is what Erich wants. Erich says: > Whichever action this would mean is philosophical by nature. Is a > shut down firewall open or closed by definition? My personal > preference would be 'lock everything up except for the management > interfaces'. I agree with this definition, except I would permit connections _from_ addresses defined in firewall settings instead of _to_ management interface. We can tighten it even more and restrict both source and destination, but I am not sure this is necessary. Also, fwbuilder already generates a rule to permit ssh access from management addresses, so I do not have to generate any new rules to implement "stop" option. Command line options "start" and "stop" seem reasonable, I'll see what I can do. To reiterate, "stop" will turn all chains into blocking mode and only permit ssh access from management station or management network as defined in the firewall settings dialog; "start" will load the whole policy. Running script without command line option is equivalent to "start" to maintain backward compatibility. I know how to do this for iptables, but doing it for pf and ipf is going to be tricky. --vk ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Fwbuilder-discussion mailing list Fwb...@li... https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion |
From: <va...@vk...> - 2006-05-20 04:56:15
|
On May 19, 2006, at 10:00 AM, Vadim Kurland =E2=9C=8D wrote: > > On May 19, 2006, at 9:27 AM, ted creedon wrote: > >> Vadim, >> >> Comments? >> >> tedc >> >> #!/bin/sh >> set -x >> #stop and clean up >> iptables --flush >> iptables --flush -t nat >> iptables --flush -t mangle >> iptables --zero >> >> >> iptables -L|g Chain|cut -d " " -f 2 > /tmp/foo >> for i in `cat /tmp/foo`;do iptables -X $i;done >> #rm /tmp/foo >> iptables -L >> >> #start >> iptables --policy INPUT ACCEPT >> iptables --policy OUTPUT ACCEPT >> iptables --policy FORWARD ACCEPT >> iptables -L >> > > this leaves firewall wide open, I am not sure this is what Erich =20 > wants. > > Erich says: > >> Whichever action this would mean is philosophical by nature. Is a =20 >> shut down firewall open or closed by definition? My personal =20 >> preference would be 'lock everything up except for the management =20 >> interfaces'. > > I agree with this definition, except I would permit connections =20 > _from_ addresses defined in firewall settings instead of _to_ =20 > management interface. We can tighten it even more and restrict both =20= > source and destination, but I am not sure this is necessary. Also, =20 > fwbuilder already generates a rule to permit ssh access from =20 > management addresses, so I do not have to generate any new rules to =20= > implement "stop" option. > > Command line options "start" and "stop" seem reasonable, I'll see =20 > what I can do. To reiterate, "stop" will turn all chains into =20 > blocking mode and only permit ssh access from management station or =20= > management network as defined in the firewall settings dialog; =20 > "start" will load the whole policy. Running script without command =20 > line option is equivalent to "start" to maintain backward =20 > compatibility. > > I know how to do this for iptables, but doing it for pf and ipf is =20 > going to be tricky. Actually, I take that back, it is equally tricky for iptables too. =20 The problem is that I have to support three script formats for =20 iptables: straight shell script where each iptables command is =20 executed by calling /usr/sbin/iptables with parameters, and two =20 variants that use iptables-restore. One of the variations for =20 iptables-restore uses shell "document here" method where it copies =20 part of the script to the standard input of iptables-restore. It is =20 hard to split generated rules so that only part of them would be fed =20 to iptables-restore when script is called with "stop" parameter. This =20= is essentially the same difficulty that I have with scripts for pf =20 and ipf where all the rules are in a separate file which is loaded as =20= the whole. Since we are in the very advanced stage of development for 2.1, with =20 just weeks before public beta, I do not want to make significant =20 changes to the code to add support for the "stop" option. It may be =20 just easier to generate a script that would block everything except =20 for ssh access to the firewall from management machines and =20 permanently store it on the firewall. If running regular script with =20 parameter "stop" was acceptable, it should be also acceptable if one =20 has to run another script to achieve the same goal. It would be =20 better if the script was automatically produced but the =20 implementation of this feature requires rather complicated =20 refactoring of the code. --vk |
From: ted c. <tcr...@ea...> - 2006-05-21 01:01:04
|
Keep it simple. A shell scrip start and stop will do ted -----Original Message----- From: fwb...@li... [mailto:fwb...@li...] On Behalf Of = Vadim Kurland ? Sent: Friday, May 19, 2006 9:56 PM To: Vadim Kurland ? Cc: ted creedon; fwb...@li... Subject: Re: [Fwbuilder-discussion] fwbuilder stop On May 19, 2006, at 10:00 AM, Vadim Kurland ? wrote: > > On May 19, 2006, at 9:27 AM, ted creedon wrote: > >> Vadim, >> >> Comments? >> >> tedc >> >> #!/bin/sh >> set -x >> #stop and clean up >> iptables --flush >> iptables --flush -t nat >> iptables --flush -t mangle >> iptables --zero >> >> >> iptables -L|g Chain|cut -d " " -f 2 > /tmp/foo >> for i in `cat /tmp/foo`;do iptables -X $i;done >> #rm /tmp/foo >> iptables -L >> >> #start >> iptables --policy INPUT ACCEPT >> iptables --policy OUTPUT ACCEPT >> iptables --policy FORWARD ACCEPT >> iptables -L >> > > this leaves firewall wide open, I am not sure this is what Erich =20 > wants. > > Erich says: > >> Whichever action this would mean is philosophical by nature. Is a =20 >> shut down firewall open or closed by definition? My personal =20 >> preference would be 'lock everything up except for the management =20 >> interfaces'. > > I agree with this definition, except I would permit connections =20 > _from_ addresses defined in firewall settings instead of _to_ =20 > management interface. We can tighten it even more and restrict both =20 > source and destination, but I am not sure this is necessary. Also, =20 > fwbuilder already generates a rule to permit ssh access from =20 > management addresses, so I do not have to generate any new rules to =20 > implement "stop" option. > > Command line options "start" and "stop" seem reasonable, I'll see =20 > what I can do. To reiterate, "stop" will turn all chains into =20 > blocking mode and only permit ssh access from management station or =20 > management network as defined in the firewall settings dialog; =20 > "start" will load the whole policy. Running script without command =20 > line option is equivalent to "start" to maintain backward =20 > compatibility. > > I know how to do this for iptables, but doing it for pf and ipf is =20 > going to be tricky. Actually, I take that back, it is equally tricky for iptables too. =20 The problem is that I have to support three script formats for =20 iptables: straight shell script where each iptables command is =20 executed by calling /usr/sbin/iptables with parameters, and two =20 variants that use iptables-restore. One of the variations for =20 iptables-restore uses shell "document here" method where it copies =20 part of the script to the standard input of iptables-restore. It is =20 hard to split generated rules so that only part of them would be fed =20 to iptables-restore when script is called with "stop" parameter. This =20 is essentially the same difficulty that I have with scripts for pf =20 and ipf where all the rules are in a separate file which is loaded as =20 the whole. Since we are in the very advanced stage of development for 2.1, with =20 just weeks before public beta, I do not want to make significant =20 changes to the code to add support for the "stop" option. It may be =20 just easier to generate a script that would block everything except =20 for ssh access to the firewall from management machines and =20 permanently store it on the firewall. If running regular script with =20 parameter "stop" was acceptable, it should be also acceptable if one =20 has to run another script to achieve the same goal. It would be =20 better if the script was automatically produced but the =20 implementation of this feature requires rather complicated =20 refactoring of the code. --vk ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, = security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=120709&bid&3057&dat=121642 _______________________________________________ Fwbuilder-discussion mailing list Fwb...@li... https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion |
From: Erich T. <eri...@th...> - 2006-05-21 16:22:27
|
Hi Vadim, Ted after stirring it up I might as well say something :-) Vadim Kurland =E2=9C=8D wrote: >=20 =2E.. >> >> this leaves firewall wide open, I am not sure this is what Erich want= s. >> >> Erich says: >> >>> Whichever action this would mean is philosophical by nature. Is a =20 >>> shut down firewall open or closed by definition? My personal =20 >>> preference would be 'lock everything up except for the management =20 >>> interfaces'. >> >> >> I agree with this definition, except I would permit connections =20 >> _from_ addresses defined in firewall settings instead of _to_ =20 >> management interface.=20 Well, this IMHO defeats the definition of the management interface. We can tighten it even more and restrict both >> source and destination, but I am not sure this is necessary. It is not, because it can be defined in a normal firewall rule. I may=20 not have completely understood the meaning of the management interface=20 then. What exactly is the purpose of the tick box in the interface? It=20 may be there only for documentation reasons and, as I alredy mentioned,=20 as a shortcut. Under what circumstances is the management interface needed and used?=20 Typically I allow firewall access under normal operation using firewall=20 rules. If it is only used as a shortcut I would opt to drop it, and thus = remove some complexity. If the firewall script has no state then IMHO=20 the management interface serves no purpose :-( I still like fwbuilder, don't take me wrong. cheers Erich |
From: <va...@vk...> - 2006-05-21 16:42:48
|
On May 21, 2006, at 9:22 AM, Erich Titl wrote: > Hi Vadim, Ted > > after stirring it up I might as well say something :-) > > Vadim Kurland =E2=9C=8D wrote: > ... >>> >>> this leaves firewall wide open, I am not sure this is what Erich =20= >>> wants. >>> >>> Erich says: >>> >>>> Whichever action this would mean is philosophical by nature. Is =20 >>>> a shut down firewall open or closed by definition? My personal =20= >>>> preference would be 'lock everything up except for the =20 >>>> management interfaces'. >>> >>> >>> I agree with this definition, except I would permit connections =20 >>> _from_ addresses defined in firewall settings instead of _to_ =20 >>> management interface. > > Well, this IMHO defeats the definition of the management interface. > > We can tighten it even more and restrict both >>> source and destination, but I am not sure this is necessary. > > It is not, because it can be defined in a normal firewall rule. I =20 > may not have completely understood the meaning of the management =20 > interface then. What exactly is the purpose of the tick box in the =20 > interface? It may be there only for documentation reasons and, as I =20= > alredy mentioned, as a shortcut. > > Under what circumstances is the management interface needed and =20 > used? Typically I allow firewall access under normal operation =20 > using firewall rules. If it is only used as a shortcut I would opt =20 > to drop it, and thus remove some complexity. If the firewall script =20= > has no state then IMHO the management interface serves no purpose :-( management interface is used by built-in installer to figure out =20 which IP address of the firewall it should connect to. Compilers do =20 not use it when they generate firewall configuration. I agree this is =20= not entirely obvious function... As an excuse, I can point out that =20 GUI tooltip that appears if you float mouse cursor over the checkbox =20 actually says so ... --vk |
From: Erich T. <eri...@th...> - 2006-05-21 16:54:51
|
Vadim Kurland =E2=9C=8D wrote: >=20 > On May 21, 2006, at 9:22 AM, Erich Titl wrote: >=20 >> Hi Vadim, Ted >> >> after stirring it up I might as well say something :-) >> >> Vadim Kurland =E2=9C=8D wrote: >> ... >> >>>> >>>> this leaves firewall wide open, I am not sure this is what Erich =20 >>>> wants. >>>> >>>> Erich says: >>>> >>>>> Whichever action this would mean is philosophical by nature. Is a = =20 >>>>> shut down firewall open or closed by definition? My personal =20 >>>>> preference would be 'lock everything up except for the management = =20 >>>>> interfaces'. >>>> >>>> >>>> >>>> I agree with this definition, except I would permit connections =20 >>>> _from_ addresses defined in firewall settings instead of _to_ =20 >>>> management interface. >> >> >> Well, this IMHO defeats the definition of the management interface. >> >> We can tighten it even more and restrict both >> >>>> source and destination, but I am not sure this is necessary. >> >> >> It is not, because it can be defined in a normal firewall rule. I may= =20 >> not have completely understood the meaning of the management =20 >> interface then. What exactly is the purpose of the tick box in the =20 >> interface? It may be there only for documentation reasons and, as I =20 >> alredy mentioned, as a shortcut. >> >> Under what circumstances is the management interface needed and used?= =20 >> Typically I allow firewall access under normal operation using=20 >> firewall rules. If it is only used as a shortcut I would opt to drop = >> it, and thus remove some complexity. If the firewall script has no=20 >> state then IMHO the management interface serves no purpose :-( >=20 >=20 >=20 > management interface is used by built-in installer to figure out which= =20 > IP address of the firewall it should connect to. Compilers do not use = > it when they generate firewall configuration. I agree this is not=20 > entirely obvious function... As an excuse, I can point out that GUI=20 > tooltip that appears if you float mouse cursor over the checkbox =20 > actually says so ... Good point, in my case I use putty instances for installation so this=20 does play a rule in my environment. On the other hand only one management interface should then be allowed,=20 which AFAIK is not the case. Or will the built in installer cycle=20 through all addresses? cheers Erich |
From: <va...@vk...> - 2006-05-21 17:31:19
|
On May 21, 2006, at 9:54 AM, Erich Titl wrote: > Vadim Kurland =E2=9C=8D wrote: >> On May 21, 2006, at 9:22 AM, Erich Titl wrote: >>> Hi Vadim, Ted >>> >>> after stirring it up I might as well say something :-) >>> >>> Vadim Kurland =E2=9C=8D wrote: >>> ... >>> >>>>> >>>>> this leaves firewall wide open, I am not sure this is what =20 >>>>> Erich wants. >>>>> >>>>> Erich says: >>>>> >>>>>> Whichever action this would mean is philosophical by nature. =20 >>>>>> Is a shut down firewall open or closed by definition? My =20 >>>>>> personal preference would be 'lock everything up except for =20 >>>>>> the management interfaces'. >>>>> >>>>> >>>>> >>>>> I agree with this definition, except I would permit =20 >>>>> connections _from_ addresses defined in firewall settings =20 >>>>> instead of _to_ management interface. >>> >>> >>> Well, this IMHO defeats the definition of the management interface. >>> >>> We can tighten it even more and restrict both >>> >>>>> source and destination, but I am not sure this is necessary. >>> >>> >>> It is not, because it can be defined in a normal firewall rule. =20 >>> I may not have completely understood the meaning of the =20 >>> management interface then. What exactly is the purpose of the =20 >>> tick box in the interface? It may be there only for =20 >>> documentation reasons and, as I alredy mentioned, as a shortcut. >>> >>> Under what circumstances is the management interface needed and =20 >>> used? Typically I allow firewall access under normal operation =20 >>> using firewall rules. If it is only used as a shortcut I would =20 >>> opt to drop it, and thus remove some complexity. If the firewall =20= >>> script has no state then IMHO the management interface serves no =20= >>> purpose :-( >> management interface is used by built-in installer to figure out =20 >> which IP address of the firewall it should connect to. Compilers =20 >> do not use it when they generate firewall configuration. I agree =20 >> this is not entirely obvious function... As an excuse, I can =20 >> point out that GUI tooltip that appears if you float mouse cursor =20= >> over the checkbox actually says so ... > > Good point, in my case I use putty instances for installation so =20 > this does play a rule in my environment. > > On the other hand only one management interface should then be =20 > allowed, which AFAIK is not the case. Or will the built in =20 > installer cycle through all addresses? I did not think about that... The internal API and XML DTD really =20 allow only one management address. I think if you check more than one =20= interface as "management" , the address of the last checked will be =20 used. --vk |