Re: RFC: my firewall ruleset(s)
On 2005-10-23 12:12, Chuck Swiger <[EMAIL PROTECTED]> wrote: > You have anti-spoofing for the lookback, lo0 interface, but not for > your other interfaces. You should add anti-spoofing rules, and also > block strict and loose source routing [1]: > > # Stop strict and loose source routing > add deny log all from any to any ipoptions ssrr > add deny log all from any to any ipoptions lsrr Agreed. Please note that this is ``an extra layer of protection'' though. The relevant bits are already disabled through sysctl settings, by default, and have to be explicitly enabled: % flame:/home/keramida$ sysctl -a | fgrep accept_source % net.inet.ip.accept_sourceroute: 0 % flame:/home/keramida$ sysctl -a | fgrep redirect % net.inet.ip.redirect: 1 % net.inet.icmp.log_redirect: 1 % net.inet.icmp.drop_redirect: 1 % net.inet6.ip6.redirect: 1 % flame:/home/keramida$ I'm sure Chuck already knows this. Just adding a minor note, to make sure you Eric don't get the wrong impression that a firewall is an absolute *requirement* to block these. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: my firewall ruleset(s)
Eric F Crist wrote: [ ... ] Ugh. :-) IPFW knows how to increment rule numbers all by itself; you can get rid of the "rulenum1=`expr $rulenum1 + 50`" stuff. I do this so that I have sufficient space between rules for my own sanity. By default, IPFW numbers rules that increment by 1. I have a need on occasion to add or remove a rule on the fly. Perhaps there is a better way? The default increment should be 100, and it is controlled by: Automatic rule numbers are assigned by incrementing the last non- default rule number by the value of the sysctl variable net.inet.ip.fw.autoinc_step which defaults to 100. If this is not possible (e.g. because we would go beyond the maximum allowed rule number), the number of the last non-default value is used instead. The breakdown of sh functions like setup_loopback, setup_keepstate, setup_ntp is fine if you want to play with shell scripts, but it scatters your IPFW rules into different places. I'd rather see something that closely resembles what "ipfw list" gives you. The reasoning behind this is so I have a single firewall script for all of my servers. At some point in the very near future, there will be a cron job on each server the pulls the current script from a central source. Depending on the rc.conf entries on that server, the firewall script will be executed accordingly. This allows me to edit one script and have it apply to multiple systems. I'm calling the functions for basic components, rather than writing the whole thing out each time. Large-scale firewall deployments (think Cisco Enterprise Manager, or Edition, or whatever it's called) use such techniques to manage hundreds or thousands of firewalls, but they have several weaknesses, in particular the central distribution server becomes a target, which, if compromised, can then be used to compromise all of the firewall boxes pulling down rulesets. One of the whole reasons for setting up multiple firewalls and multiple rulesets is to obtain "defense in depth". Using a central config mechanism contradicts that design intention. Therefore, I am convinced that a firewall ought to be self-contained in terms of enforcing a security policy, and should have as little dependence on any other host as practical, none at all, if possible. Other opinions are possible, but Microsoft's domain-aware firewall and proxy box is a good example of what this can lead to. You could chain several ports together into a list rather than listing them all seperately as individual rules, IPFW will end up doing less work. Is this a 'good' way to do things? The server in this instance has really nothing else to do, save serving up a couple website with low traffic. It's more efficient from the standpoint of IPFW workload, but if the traffic volume is low, go with whatever design seems the easiest to work with and understand. I find something like this: # block all NetBIOS, domain-server, UPnP traffic add deny log tcp from any to any 135-139,445,5000 ...to be more clear than 4 seperate lines, YMMV. You have anti-spoofing for the lookback, lo0 interface, but not for your other interfaces. You should add anti-spoofing rules, and also block strict and loose source routing [1]: Point taken. I pulled those rules from the default script that ships with FreeBSD. I did a brief google search on the strict and loose source routing. Can you share more information? # Stop strict and loose source routing add deny log all from any to any ipoptions ssrr add deny log all from any to any ipoptions lsrr Sure. In the early days of TCP/IP networking, people didn't always have conventions like default routes and routers which could figure out where to send traffic for any destination, so there is a mechanism for routing traffic directly, hop by hop, which supercedes the normal behavior of routers and many firewalls. It conceptually resembles the bang-path notation used for UUCP email before SMTP email using domains via DNS was available. It can be used to pretend that traffic from outside your network came from an inside IP, or from the firewall itself, which often lets that traffic go through. In practice nowadays, the LSR and SSR options are pretty much *only* used for malicious traffic, except once in a while by people writing a TCP/IP stack who are testing the option handling code. See page 15 & 17-20 of RFC-791, http://www.rfc-editor.org/rfc/rfc791.txt: The following internet options are defined: CLASS NUMBER LENGTH DESCRIPTION - -- -- --- 0 0 -End of Option list. This option occupies only 1 octet; it has no length octet. 0 1 -No Operation. This option occupies only 1 octet; it has no length octet. 0 2 11Security. Used to carry Security, Compartmentation, User
Re: RFC: my firewall ruleset(s)
On Oct 23, 2005, at 11:12 AM, Chuck Swiger wrote: Eric F Crist wrote: Hey all. I'm relatively new to shell scripting and I'm looking for some comments on my firewall script. Comments on either the ipfw rules themselves or on my scripting lack of ability would be appreciated. Ugh. :-) IPFW knows how to increment rule numbers all by itself; you can get rid of the "rulenum1=`expr $rulenum1 + 50`" stuff. I do this so that I have sufficient space between rules for my own sanity. By default, IPFW numbers rules that increment by 1. I have a need on occasion to add or remove a rule on the fly. Perhaps there is a better way? The breakdown of sh functions like setup_loopback, setup_keepstate, setup_ntp is fine if you want to play with shell scripts, but it scatters your IPFW rules into different places. I'd rather see something that closely resembles what "ipfw list" gives you. The reasoning behind this is so I have a single firewall script for all of my servers. At some point in the very near future, there will be a cron job on each server the pulls the current script from a central source. Depending on the rc.conf entries on that server, the firewall script will be executed accordingly. This allows me to edit one script and have it apply to multiple systems. I'm calling the functions for basic components, rather than writing the whole thing out each time. You could chain several ports together into a list rather than listing them all seperately as individual rules, IPFW will end up doing less work. Is this a 'good' way to do things? The server in this instance has really nothing else to do, save serving up a couple website with low traffic. You have anti-spoofing for the lookback, lo0 interface, but not for your other interfaces. You should add anti-spoofing rules, and also block strict and loose source routing [1]: Point taken. I pulled those rules from the default script that ships with FreeBSD. I did a brief google search on the strict and loose source routing. Can you share more information? # Stop strict and loose source routing add deny log all from any to any ipoptions ssrr add deny log all from any to any ipoptions lsrr You should give some thought to ICMP filtering. Consider something like: add allow icmp from any to any icmptypes 0,3,4,8,11,12 This was simply forgotten. Thanks! You should use the log command more when developing a ruleset, to see what traffic you are blocking or permitting, until you've gotten your rules and network finalized. Is there a way to direct different rules to different facilities or log files? This is the primary reason I have not enabled logging more. -- -Chuck [1]: This is known to hackers as the "how to go through a firewall as if it wasn't there" IP option if you don't block these. :-) Thanks for the great input! I'll work further to develop my script. Part of my reason for getting so involved with the shell scripting on this ruleset is so that I have an actual project with a purpose in front of me to develop my scripting abilities. ___ Eric F Crist "I am so smart, S.M.R.T!" Secure Computing Networks -Homer J Simpson ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: my firewall ruleset(s)
Eric F Crist wrote: Hey all. I'm relatively new to shell scripting and I'm looking for some comments on my firewall script. Comments on either the ipfw rules themselves or on my scripting lack of ability would be appreciated. Ugh. :-) IPFW knows how to increment rule numbers all by itself; you can get rid of the "rulenum1=`expr $rulenum1 + 50`" stuff. The breakdown of sh functions like setup_loopback, setup_keepstate, setup_ntp is fine if you want to play with shell scripts, but it scatters your IPFW rules into different places. I'd rather see something that closely resembles what "ipfw list" gives you. You could chain several ports together into a list rather than listing them all seperately as individual rules, IPFW will end up doing less work. You have anti-spoofing for the lookback, lo0 interface, but not for your other interfaces. You should add anti-spoofing rules, and also block strict and loose source routing [1]: # Stop strict and loose source routing add deny log all from any to any ipoptions ssrr add deny log all from any to any ipoptions lsrr You should give some thought to ICMP filtering. Consider something like: add allow icmp from any to any icmptypes 0,3,4,8,11,12 You should use the log command more when developing a ruleset, to see what traffic you are blocking or permitting, until you've gotten your rules and network finalized. -- -Chuck [1]: This is known to hackers as the "how to go through a firewall as if it wasn't there" IP option if you don't block these. :-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: my firewall ruleset(s)
On Oct 23, 2005, at 10:44 AM, Eric F Crist wrote: Hey all. I'm relatively new to shell scripting and I'm looking for some comments on my firewall script. Comments on either the ipfw rules themselves or on my scripting lack of ability would be appreciated. Thanks. ___ Eric F Crist "I am so smart, S.M.R.T!" Secure Computing Networks -Homer J Simpson Sorry to post a shell program as an attachment. I wasn't thinking. Please don't run the shell program - it'll set an open firewall on your *nix system if you're root. ___ Eric F Crist "I am so smart, S.M.R.T!" Secure Computing Networks -Homer J Simpson ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RFC: my firewall ruleset(s)
Hey all. I'm relatively new to shell scripting and I'm looking for some comments on my firewall script. Comments on either the ipfw rules themselves or on my scripting lack of ability would be appreciated. Thanks. nerp.firewall Description: Binary data ___ Eric F Crist "I am so smart, S.M.R.T!" Secure Computing Networks -Homer J Simpson ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
