On 3/23/14, 6:16 AM, Ian Smith wrote:
On Sat, 22 Mar 2014 22:39:36 -0700, Julian Elischer wrote:
> reposting with a useful subject line and more comments
>
> On 3/22/14, 10:33 PM, Julian Elischer wrote:
> >
> > in ipfw that's up to you..
> > but I usually put the check-state quite early in my rule sets.
> >
> On 3/22/14, 1:34 AM, Ian Smith wrote:
> > Firstly, that's the one page in the handbook (that I know of) that needs
> > completely nuking. It contains many factual errors as well as weird
> > notions, and will only tend to mislead you; consult ipfw(8) and prosper.
> > I'd say refer to the examples in rc.firewall but it too is in disrepair.
Firstly, I owe an apology to the doc crew, one of whom contacted me
privately to point out that the ipfw page has had quite a massaging
lately, and work is ongoing. I'm sorry for not checking again first.
> I am working on a new rc.firewall that is much more efficient.
> the trouble is that the script to make it do what I want is a bit more
> complicated.
> I'll put it out for discussion later. maybe tonight.
Great. Maybe my failed rc.firewall patch from '11 can still be useful.
rather than show the script (for now)
here's the generated output for a machine with 2 interfaces performing
NAT on behalf of its
bretheren inside.
inside nets are covered in table1
table 2 specifies your DNS secondaries if you are serving dns as a
primary.
table 13 is all the addresses you should never put out.. or get.
I run a very similar firewall on my machines but I'm generalising it.
curious to see what people make of it :-)
I haven't run this since I started rewriting the script so it may have
errors.
count the following:
1/ the number of rules any given packet traverses
2/ the number of tests done on each packet
('from any to any ' is no tests, from me to any is 1 test, 'from me to
you' is 2 tests.)
One if the things that drives me crazy with the current firewalls is
that incoming and
outgoing packets from multiple interfaces traverse the same rules, in
the same direction.
In this set each interface gets its own rules.. in the scripts they
actually have their own files,
which are included to give this aggregate ruleset.
comments welcome (bugs expected)
/sbin/ipfw table add 13 0.0.0.0/8
/sbin/ipfw table add 13 10.0.0.0/8
/sbin/ipfw table add 13 169.254.0.0/16
/sbin/ipfw table add 13 172.16.0.0/12
/sbin/ipfw table add 13 192.0.2.0/24
/sbin/ipfw table add 13 192.168.0.0/16
/sbin/ipfw table add 13 224.0.0.0/4
/sbin/ipfw table add 13 240.0.0.0/4
/sbin/sysctl net.inet.ip.fw.autoinc_step=2
/sbin/sysctl net.inet.ip.fw.default_to_accept=0
/sbin/sysctl net.inet.ip.fw.one_pass=0
/sbin/ipfw add 0 set 0 add pass ipv6-icmp from :: to ff02::/16
/sbin/ipfw add 2 set 0 add pass ipv6-icmp from fe80::/10 to fe80::/10
/sbin/ipfw add 4 set 0 add pass ipv6-icmp from fe80::/10 to ff02::/16
/sbin/ipfw add 6 set 0 add pass ipv6-icmp from any to any icmp6types 1
/sbin/ipfw add 8 set 0 add pass ipv6-icmp from any to any icmp6types
2,135,136
/sbin/ipfw add 500 set 0 skipto 1000 ip from any to any in recv lo0
/sbin/ipfw add 502 set 0 skipto 1500 ip from any to any out xmit lo0
/sbin/ipfw add 504 set 0 deny all from 127.0.0.1 to any
/sbin/ipfw add 506 set 0 deny all from any to 127.0.0.1
/sbin/ipfw add 508 set deny all from any to ::1
/sbin/ipfw add 510 set deny all from ::1 to any
/sbin/ipfw add 512 set 0 skipto 2000 ip from any to any in recv xn0
/sbin/ipfw add 514 set 0 skipto 2500 ip from any to any out xmit xn0
/sbin/ipfw add 516 set 0 skipto 3000 ip from any to any in recv xn1
/sbin/ipfw add 518 set 0 skipto 3500 ip from any to any out xmit xn1
/sbin/ipfw add 520 set 0 deny ip from any to any
#lo0 rules
/sbin/ipfw add 1000 set 0 allow all from any to any
/sbin/ipfw add 1500 set 0 allow all from any to any
#xn0 input packets
/sbin/ipfw add 2000 set 0 skipto 2200 ip from any to MY_ADDR
/sbin/ipfw add 2002 set 0 reject ip from any to table(13)
/sbin/ipfw add 2004 set 0 allow udp from any to 255.255.255.255
/sbin/ipfw add 2006 set 0 allow udp from MY_NET to MY_BCASTADDR
/sbin/ipfw add 2008 set 0 drop ip from any to any
/sbin/ipfw add 2200 set 0 check-state
/sbin/ipfw add 2202 set 0 reject ip from table(13) to any
/sbin/ipfw add 2204 set 0 allow udp from any to any 53 keep-state
/sbin/ipfw add 2206 set 0 allow tcp from table(2) to any setup 53
keep_state
/sbin/ipfw add 2208 set 1 allow tcp from any to any
25,993,995,597,514,80,443 setup keep-state
/sbin/ipfw add 2210 set 0 allow udp from any to any frag
/sbin/ipfw add 2212 set 0 allow icmp from any to any keep-state
/sbin/ipfw add 2214 set 3 nat 1 ip from any to any
/sbin/ipfw add 2216 set 3 accept ip from any to table(1)
/sbin/ipfw add 2218 set 0 drop ip from any to any
#xn0 output packets
/sbin/ipfw add 2500 set 0 skipto 2700 ip from MY_ADDR to any
/sbin/ipfw add 2502 set 0 drop ip from not table(1) to any
/sbin/ipfw add 2504 set 0 reject ip from any to table(13)
/sbin/ipfw add 2506 set 3 nat 1 all from table(1) to any
/sbin/ipfw add 2508 set 3 accept all from MY_ADDR to any
/sbin/ipfw add 2510 set 0 drop ip from any to any
/sbin/ipfw add 2700 set 0 check-state
/sbin/ipfw add 2702 set 0 reject ip from any to table(13)
/sbin/ipfw add 2704 set 0 allow tcp from any to any setup keep-state
/sbin/ipfw add 2706 set 0 allow tcp from any to any established keep-state
/sbin/ipfw add 2708 set 0 allow udp from any to any keep-state
/sbin/ipfw add 2710 set 0 allow icmp from any to any keep-state
/sbin/ipfw add 2712 set 0 drop ip from any to any
#xn1 input packets
/sbin/ipfw add 3000 set 0 skipto 3200 ip from any to 10.11.50.2 # to me?
/sbin/ipfw add 3002 set 0 deny log ip from any to any
/sbin/ipfw add 3200 set 0 check-state
/sbin/ipfw add 3202 set 0 allow icmp from any to any icmptype 0,3,8
keep-state
/sbin/ipfw add 3204 set 0 deny log ip from any to any
xn1 output packets
/sbin/ipfw add 3500 set 0 skipto 3700 ip from 10.11.50.2 to any # from me?
/sbin/ipfw add 3502 set 0 deny log ip from any to any
/sbin/ipfw add 3700 set 0 check-state
/sbin/ipfw add 3702 set 0 allow tcp from any to any setup keep-state
/sbin/ipfw add 3704 set 0 allow ip from any to any keep-state
> as for the handbook pages.. after we see how the new firewall rules work
> we can see about rewriting the page.
Yes, well it seems there's a newer framework worth hanging it on now.
I guess we should drop freebsd-security@ until there's some news?
cheers, Ian
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"