Re: rc.firewall quick change
Ian Smith wrote:
On Thu, 13 Nov 2008, Julian Elischer wrote:
At home I use the following change.
basically, instead of doing 8 rules before and after the nat,
use a table and to 1 rule on each side.
any objections?
Only that if people are already using tables for anything, chances are
they've already used table 1 (well, it's the first one I used :) How
about using table 127 for this as a rather less likely prior choice?
yes I thought of that..
in fact it should be ${BLOCKTABLE} and let the user define what he
wants. (defaulting to 99 or something).
Remember though that a user wouldn't be using 'simple' if he's using
his own tables etc.
Apart from that, this will speed up 'simple' on a path every packet
takes, which has to be a good thing.
While I'm at it, I'll offer my own rc.firewall patch again in the
following message. Perhaps you'd care to review it in this context?
cheers, Ian
(warning, cut-n-paste patch.. will not apply)
Index: rc.firewall
===
--- rc.firewall (revision 184948)
+++ rc.firewall (working copy)
@@ -231,19 +231,24 @@
${fwcmd} add deny all from ${onet} to any in via ${iif}
# Stop RFC1918 nets on the outside interface
- ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif}
- ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif}
- ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif}
+ ${fwcmd} table 1 add 10.0.0.0/8
+ ${fwcmd} table 1 add 172.16.0.0/12
+ ${fwcmd} table 1 add 192.168.0.0/16
# Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes
RESERVED-1,
# DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class
E)
# on the outside interface
- ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif}
- ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif}
- ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif}
- ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif}
- ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif}
+ ${fwcmd} table 1 add 0.0.0.0/8
+ ${fwcmd} table 1 add 169.254.0.0/16
+ ${fwcmd} table 1 add 192.0.2.0/24
+ ${fwcmd} table 1 add 224.0.0.0/4
+ ${fwcmd} table 1 add 240.0.0.0/4
+# Stop the above nets with the table
+
+ ${fwcmd} add deny all from any to table(1) via ${oif}
+
+
# Network Address Translation. This rule is placed here deliberately
# so that it does not interfere with the surrounding address-checking
# rules. If for example one of your internal LAN machines had its IP
@@ -260,19 +265,8 @@
esac
# Stop RFC1918 nets on the outside interface
- ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif}
- ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif}
- ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif}
+ ${fwcmd} add deny all from table(1) to any via ${oif}
- # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes
RESERVED-1,
- # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class
E)
- # on the outside interface
- ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif}
- ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif}
- ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif}
- ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif}
- ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif}
-
# Allow TCP through if setup succeeded
${fwcmd} add pass tcp from any to any established
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.firewall quick change
On Fri, 14 Nov 2008, Julian Elischer wrote:
Ian Smith wrote:
On Thu, 13 Nov 2008, Julian Elischer wrote:
At home I use the following change.
basically, instead of doing 8 rules before and after the nat,
use a table and to 1 rule on each side.
any objections?
Only that if people are already using tables for anything, chances are
they've already used table 1 (well, it's the first one I used :) How about
using table 127 for this as a rather less likely prior choice?
yes I thought of that..
Separate rules provide more statistics.
in fact it should be ${BLOCKTABLE} and let the user define what he wants.
(defaulting to 99 or something).
I use shell variables giving lists of interfaces to be blocked so that
there aren't very many rules:
%%%
rfc1918n=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
dmanningn=0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4
${fwcmd} add deny log all from any to ${rfc1918n} via ${oif}
${fwcmd} add deny log all from any to ${dmanningn} via ${oif}
... (divert rule)
${fwcmd} add deny log all from ${rfc1918n} to any via ${oif}
${fwcmd} add deny log all from ${dmanningn} to any via ${oif}
%%%
I use separate lists mainly for documentation purposes but they also
provide separate statistics.
Remember though that a user wouldn't be using 'simple' if he's using his own
tables etc.
Separate rules are also simplest for documentation purposes.
Apart from that, this will speed up 'simple' on a path every packet takes,
which has to be a good thing.
Are tables faster than lists of addresses? I would expect lists to be
slightly more efficient.
Bruce
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.firewall quick change
Bruce Evans wrote:
On Fri, 14 Nov 2008, Julian Elischer wrote:
Ian Smith wrote:
On Thu, 13 Nov 2008, Julian Elischer wrote:
At home I use the following change.
basically, instead of doing 8 rules before and after the nat,
use a table and to 1 rule on each side.
any objections?
Only that if people are already using tables for anything, chances
are they've already used table 1 (well, it's the first one I used :)
How about using table 127 for this as a rather less likely prior choice?
yes I thought of that..
Separate rules provide more statistics.
true but generally people don't need to distinguish between those,
and if you do then you probably want to log them.
in fact it should be ${BLOCKTABLE} and let the user define what he
wants. (defaulting to 99 or something).
I use shell variables giving lists of interfaces to be blocked so that
there aren't very many rules:
%%%
rfc1918n=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
dmanningn=0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4
${fwcmd} add deny log all from any to ${rfc1918n} via ${oif}
${fwcmd} add deny log all from any to ${dmanningn} via ${oif}
... (divert rule)
${fwcmd} add deny log all from ${rfc1918n} to any via ${oif}
${fwcmd} add deny log all from ${dmanningn} to any via ${oif}
%%%
I use separate lists mainly for documentation purposes but they also
provide separate statistics.
Remember though that a user wouldn't be using 'simple' if he's using
his own tables etc.
Separate rules are also simplest for documentation purposes.
Apart from that, this will speed up 'simple' on a path every packet
takes, which has to be a good thing.
Are tables faster than lists of addresses? I would expect lists to be
slightly more efficient.
I think the table is faster for mor ethan about 8 addresses (so we
are borderline) but it's be hard to test.. You however use two rules
so that would be slower.
In my sites I tend to have other stuff put in those tables too
Bruce
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.firewall quick change
Julian Elischer wrote: I think the table is faster for mor ethan about 8 addresses (so we are borderline) but it's be hard to test.. You however use two rules so that would be slower. I'm not a firewall expert so I won't comment on the specifics but I do want to say that as a general rule it works + fast/efficient is MUCH more important for default settings than it works really well or it works + more features. For better or worse we live in a world where most users don't read the manuals, and that includes the ones running benchmarks with default settings. OTOH I do think it would be entirely appropriate to include a better example commented out next to the fast default. I take a similar approach with the default named.conf and have had good feedback from users who appreciate pointers to more information when they actually do get curious. hth, Doug -- This .signature sanitized for your protection ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.firewall quick change
Doug Barton wrote: Julian Elischer wrote: I think the table is faster for mor ethan about 8 addresses (so we are borderline) but it's be hard to test.. You however use two rules so that would be slower. I'm not a firewall expert so I won't comment on the specifics but I do want to say that as a general rule it works + fast/efficient is MUCH more important for default settings than it works really well or it works + more features. For better or worse we live in a world where most users don't read the manuals, and that includes the ones running benchmarks with default settings. I think the change is better from the point of view that it is easier to read (for me) and behaves better. OTOH I do think it would be entirely appropriate to include a better example commented out next to the fast default. I take a similar approach with the default named.conf and have had good feedback from users who appreciate pointers to more information when they actually do get curious. hth, Doug ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.firewall quick change
On Fri, 14 Nov 2008, Julian Elischer wrote:
Julian Elischer wrote:
Ian Smith wrote:
On Thu, 13 Nov 2008, Julian Elischer wrote:
At home I use the following change.
basically, instead of doing 8 rules before and after the nat,
use a table and to 1 rule on each side.
any objections?
Only that if people are already using tables for anything, chances are
they've already used table 1 (well, it's the first one I used :) How
about using table 127 for this as a rather less likely prior choice?
yes I thought of that..
in fact it should be ${BLOCKTABLE} and let the user define what he wants.
(defaulting to 99 or something).
I prefer binary, but whatever :)
Remember though that a user wouldn't be using 'simple' if he's using his
own tables etc.
This is an important point. Please allow me a little pent-up critique:
Originally, eg for me over 10 years ago, till recently, the only way to
use the 'client' or 'simple' rulesets was to hack rc.firewall, which I
did relentlessly, like many people I'm sure .. that is, we treated it
more as a starter example, not something that could be used as is.
More recent updates have introduced rc vars that concievably make these
rulesets usable out of the box, in as much as you could tell a newbie
to FreeBSD firewalls and ipfw in particular, setup these vars for your
network, select the 'client' or 'simple' ruleset as appropriate, and you
have a fair chance of having a fairly functional and reasonably secure
firewall to get yourself online and going until you learn a bit more.
Combined with the deprecatory and in many instances just plain erroneous
info in the only section of the Handbook that I've felt to try rewriting
more or less from scratch - ie the ipfw part of the firewall chapter 31,
which suggests some quite (to me) bizarre example rulesets after having
dissed using the rc.firewall rulesets out of hand - we're not doing much
good at advocating new users trying ipfw, which I think does it some
injustice. Not intending here to deprecate pf or ipf in any way.
Anyhow, this leaves us with two good reasons that 'client' and 'simple'
sections ought to work effectively: secondly as an example illustrating
good techniques - and I think your use of a table that the user can add
entries to out of band for such as blackholing hosts/nets without having
to reconfigure or restart the firewall IS good technique - but firstly
as a basically functional and secure minimal firewall in and of itself.
It's for both those reasons (and fixing an apparent oversight) that I've
offered my unreviewed patch (which I'll do properly by PR if anyone says
it's worth pursuing), after years of not being able to fathom supposedly
usable firewall configuration for a client or small net, with or without
NAT, that has never passed =ANY= ICMP traffic, not even to or from the
hosts in one's own net! Am I missing something, thinking that matters,
and that functioning path MTU discovery matters?
so here's a slightly improved diff:
This may be a bit nitpicky, but how about keeping the firewall_simple_*
varset naming consistent, maybe firewall_simple_blocktable or something?
The 'workstation' vars have kinda busted that idea anyway, but still ..
Also maybe rephrase mentioning the draft-manning-blah after the divert?
HTH, Ian
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.firewall quick change
On Thu, 13 Nov 2008, Julian Elischer wrote:
At home I use the following change.
basically, instead of doing 8 rules before and after the nat,
use a table and to 1 rule on each side.
any objections?
Only that if people are already using tables for anything, chances are
they've already used table 1 (well, it's the first one I used :) How
about using table 127 for this as a rather less likely prior choice?
Apart from that, this will speed up 'simple' on a path every packet
takes, which has to be a good thing.
While I'm at it, I'll offer my own rc.firewall patch again in the
following message. Perhaps you'd care to review it in this context?
cheers, Ian
(warning, cut-n-paste patch.. will not apply)
Index: rc.firewall
===
--- rc.firewall (revision 184948)
+++ rc.firewall (working copy)
@@ -231,19 +231,24 @@
${fwcmd} add deny all from ${onet} to any in via ${iif}
# Stop RFC1918 nets on the outside interface
- ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif}
- ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif}
- ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif}
+ ${fwcmd} table 1 add 10.0.0.0/8
+ ${fwcmd} table 1 add 172.16.0.0/12
+ ${fwcmd} table 1 add 192.168.0.0/16
# Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes
RESERVED-1,
# DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class
E)
# on the outside interface
- ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif}
- ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif}
- ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif}
- ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif}
- ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif}
+ ${fwcmd} table 1 add 0.0.0.0/8
+ ${fwcmd} table 1 add 169.254.0.0/16
+ ${fwcmd} table 1 add 192.0.2.0/24
+ ${fwcmd} table 1 add 224.0.0.0/4
+ ${fwcmd} table 1 add 240.0.0.0/4
+# Stop the above nets with the table
+
+ ${fwcmd} add deny all from any to table(1) via ${oif}
+
+
# Network Address Translation. This rule is placed here deliberately
# so that it does not interfere with the surrounding address-checking
# rules. If for example one of your internal LAN machines had its IP
@@ -260,19 +265,8 @@
esac
# Stop RFC1918 nets on the outside interface
- ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif}
- ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif}
- ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif}
+ ${fwcmd} add deny all from table(1) to any via ${oif}
- # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes
RESERVED-1,
- # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class
E)
- # on the outside interface
- ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif}
- ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif}
- ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif}
- ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif}
- ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif}
-
# Allow TCP through if setup succeeded
${fwcmd} add pass tcp from any to any established
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]
