Re: [suse-security] firewals package - NFS exports
I wouldn't mess up rc.config with "code". Instead it would be
Agreed - it was only a first go. And fine if it was just me...
better to stick with rc.config as a bunch of variables and ask SuSE to extend the firewall script like sketched below (didn't
Yes please - Marc??
+# optional(?): empty function body as a fallback, +# would be overridden when sourcing the specified script +fw_custom_rules() { + # EMPTY +} + +# make use of what the user supplies us with +[ -r "$FW_CUSTOMRULES" ] && . "$FW_CUSTOMRULES"
Excellent idea. If $FW_CUSTOMRULES was sourced at the location in SuSEfirewall from which I called fw_custom_rules, the need to call a function would go away. For those 2 cases where I had to insert a rule before already existing ones, instead of appending it to the end of the chain, some other mechanism would be useful too. Here it would be easier to call a function, rather than have a new file for each location at which it might be useful to insert more custom rules. For consistency it might be better to stick with a function as well for custom rules appended to the input chain. I also used this for appending to output rules: FW_BLOCK_DOMAINS="no" FW_BLOCK_DOMAINS="yes" # uncomment to block listed domains # # This needs to do DNS lookups, which can take a while. It would be better # off in a background process. fw_block_domains() { domainlist="/etc/local/firewall.block" if [ ! -r "$domainlist" ]; then echo "Can't read list of domains to block! ($domainlist)" else echo "Blocking domains from list: $domainlist" while read; do #echo "read: $REPLY" test -z "$REPLY" && continue test "$REPLY" != "${REPLY#\#}" && continue echo "Blocking: $REPLY" $IPCHAINS -A output -j "$REJECT" -d "$REPLY" \ 2>&1 | grep -v 'for more information.$' done < "$domainlist" fi } (A quick way to get rid of adpop.com & Co.) I would favour calling functions at various places in SuSEfirewall, with the functions being declared empty by default. Any/all could be defined in another file sourced near the start of SuSEfirewall.
+# script's filename with local rules in addition to or as a +# substitute for what can be done with the FW_* variables +# e.g. FW_CUSTOMRULES=/sbin/init.d/rc.d/firewall.custom +FW_CUSTOMRULES=""
Yes, but I'd put it into firewall.rc.config.
- leave the FW_ variables alone and doing it *all* yourself :)
Possible already by replacing SuSEfirewall with another script...
- switching between several rule sets just by pointing to a different function (i.e. script)
Possible already by "SuSEfirewall file someotherfile"
- deliver some "usually asked for" scripts in /usr/doc/packages with the SuSEfirewall script
Yes please :-) 2 other suggestions: 1) This "dns" is confusing. I would have thought to be rather common to run xntpd, even on dial-up connections? Could that be changed to # Common: "dns", or "domain, ntp" ?? FW_ALLOW_INCOMING_HIGHPORTS_TCP="yes" # Common: "ftp-data" (sadly!) FW_ALLOW_INCOMING_HIGHPORTS_UDP="yes" # Common: "dns" # # For the ntpdate command to work, the ntp port must belisted here. # Note: "dns" is a script-internal string. To specify the dns # port, use "domain"!! -VK FW_ALLOW_INCOMING_HIGHPORTS_TCP="ftp-data" FW_ALLOW_INCOMING_HIGHPORTS_UDP="domain ntp" 2) Taking the risk of greatly embarrassing myself, would it be possible to add a couple more sentences to explain what DMZ is good for??? Volker
On Wed, Sep 06, 2000 at 16:46 +1200, Volker Kuhlmann wrote:
+# optional(?): empty function body as a fallback, +# would be overridden when sourcing the specified script +fw_custom_rules() { + # EMPTY +} + +# make use of what the user supplies us with +[ -r "$FW_CUSTOMRULES" ] && . "$FW_CUSTOMRULES"
Excellent idea. If $FW_CUSTOMRULES was sourced at the location in SuSEfirewall from which I called fw_custom_rules, the need to call a function would go away.
You didn't get the idea of my patch. :) Yes, the custom file gets sourced. But *only* to redefine the (previously empty) functions. Their invocations could get scattered all over the "real" code. And in later versions SuSE (as well as following them the users) are free to expand the number of hooks and rearrange the code. Without experiencing unnecessary "collisions" when updating the SuSE provided script. But still with all the advantages of personal preferences getting obeyed.
For those 2 cases where I had to insert a rule before already existing ones, instead of appending it to the end of the chain, some other mechanism would be useful too. Here it would be easier to call a function, rather than have a new file for each location at which it might be useful to insert more custom rules. For consistency it might be better to stick with a function as well for custom rules appended to the input chain.
That's exactly what the previously provided "architecture" is able to give at your hands. :> To summarize: - collect all the "static" switches and parameters in rc.conf or wherever they reside - don't ever touch the distributor's provided parts as long as you can achieve your goals otherwise, instead expect them to provide enough (better: well placed) hooks for your customization and - override the defaults with the methods created for this very purpose, don't try to force things The latter two items go close together and will save you from trouble when updating. The time you spend doing it the appropriate way pays back when updates go smoother.
I would favour calling functions at various places in SuSEfirewall, with the functions being declared empty by default. Any/all could be defined in another file sourced near the start of SuSEfirewall.
It's all there. All that's left to do in this thread is to identify how many hooks users need and where to place them.
+# script's filename with local rules in addition to or as a +# substitute for what can be done with the FW_* variables +# e.g. FW_CUSTOMRULES=/sbin/init.d/rc.d/firewall.custom +FW_CUSTOMRULES=""
Yes, but I'd put it into firewall.rc.config.
I don't know. And strictly speaking I don't really care. :) I've never experienced any version of SuSE Linux beyond 5.3 ...
- leave the FW_ variables alone and doing it *all* yourself :)
Possible already by replacing SuSEfirewall with another script...
That's a chance you _always_ had and will always have. When you're not satisfied with the template SuSE provides, feel free to drop a script of your own into the boot sequence.
2) Taking the risk of greatly embarrassing myself, would it be possible to add a couple more sentences to explain what DMZ is good for???
Just place a hint to the little-idiot Firewall HowTo somewhere for the interested reader to follow (it was mentioned in the SuSE lists several times and should be available in the archives). When a user has the distro handbook only when planning / setting up the firewall topology, there's probably no need for the "more advanced topics". But I could be mistaking in this. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
Hi, btw people, SuSEfirewall/firewals v3.2 is available at www.suse.de/~marc
better to stick with rc.config as a bunch of variables and ask SuSE to extend the firewall script like sketched below (didn't
Yes please - Marc??
+# optional(?): empty function body as a fallback, +# would be overridden when sourcing the specified script +fw_custom_rules() { + # EMPTY +} + +# make use of what the user supplies us with +[ -r "$FW_CUSTOMRULES" ] && . "$FW_CUSTOMRULES"
Excellent idea. If $FW_CUSTOMRULES was sourced at the location in SuSEfirewall from which I called fw_custom_rules, the need to call a function would go away.
I already thought heavily about adding "hooks" where people can plugin customized rules. But I realized, that it is hopeless - where should they be loaded. The problem is, that the firewals script tries to be perfect, hence the rulesetup is pretty complicated. no easy way to make a hook somewhere which will sattisfy more than 50% of the people who want this feature I think. If you can come up with a good idea, solution or point me to the location in the file which you think would be the best place to install such a hook - tell me.
+# script's filename with local rules in addition to or as a +# substitute for what can be done with the FW_* variables +# e.g. FW_CUSTOMRULES=/sbin/init.d/rc.d/firewall.custom +FW_CUSTOMRULES=""
Yes, but I'd put it into firewall.rc.config.
the FW_CUSTOMRULES config would be in firewall.rc.config, however the custom file should be /etc/rc.config.d/firewall.custom.rc.config or something worse ;-)
- leave the FW_ variables alone and doing it *all* yourself :)
Possible already by replacing SuSEfirewall with another script...
you can also hack your lines into the script.
- switching between several rule sets just by pointing to a different function (i.e. script)
Possible already by "SuSEfirewall file someotherfile"
yes. people should occasionally check for updates and take a look at the CHANGES file or type "SuSEfirewall help" :)
- deliver some "usually asked for" scripts in /usr/doc/packages with the SuSEfirewall script
Yes please :-)
if you mean "usual configurations" -> there an EXAMPLES file in the doc directory. if you mean such sustomized scripts - once it really can be implemented in a useful way, send me yours :)
2 other suggestions:
1) This "dns" is confusing. I would have thought to be rather common to run xntpd, even on dial-up connections? Could that be changed to # Common: "dns", or "domain, ntp" ??
FW_ALLOW_INCOMING_HIGHPORTS_TCP="yes" # Common: "ftp-data" (sadly!) FW_ALLOW_INCOMING_HIGHPORTS_UDP="yes" # Common: "dns" # # For the ntpdate command to work, the ntp port must belisted here. # Note: "dns" is a script-internal string. To specify the dns # port, use "domain"!! -VK FW_ALLOW_INCOMING_HIGHPORTS_TCP="ftp-data" FW_ALLOW_INCOMING_HIGHPORTS_UDP="domain ntp"
I'll enhance that a bit, yeah
2) Taking the risk of greatly embarrassing myself, would it be possible to add a couple more sentences to explain what DMZ is good for???
there are already good books about that. chapman/zwicky: building internet firewalls cheswick/bellovin: firewall and internet security Greets, Marc -- Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: marc@suse.de Function: Security Research and Advisory PGP: "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka" Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C Private: http://www.suse.de/~marc SuSE: http://www.suse.de/security
* Marc Heuse wrote on Thu, Sep 07, 2000 at 21:40 +0200:
I already thought heavily about adding "hooks" where people can plugin customized rules. But I realized, that it is hopeless - where should they be loaded. The problem is, that the firewals script tries to be perfect, hence the rulesetup is pretty complicated. no easy way to make a hook somewhere which will sattisfy more than 50% of the people who want this feature I think.
Not really a hook, but maybe an idea. My firewall script uses a conf-file. In that conf file may be user-defined rules, which are set up first (and take precedence). Such a rule may look like #syntax: (net/mask|ip):[port[-port] <this again> <proto> <ipchains parameter> forward: 192.168.1.0/24:1024-1050 192.168.0.0/24:ssh tcp -j ACCEPT It's a very technical format but it (should) allows to set anything what's needed. I found it very useful i.e. when enabling ipsec. But maybe I misunderstood the problem of the "hooks" here completly... oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
participants (4)
-
Gerhard Sittig -
marc＠suse.de -
Steffen Dettmer -
Volker Kuhlmann