On 02/01/11 00:40, Kevin Wilcox wrote:
On Mon, Jan 31, 2011 at 05:58, Da Rock
<freebsd-questi...@herveybayaustralia.com.au> wrote:
Yes. Me unfortunately, but I did manage to pick it up quite quickly though.
I had a little thief attack one of my ports and attempt login on the
firewall. I had to change it to 'block in $log on $ext_if all
block out $log on $ext_if all' to actually block the traffic. Bit of a doozy
really, I'm still monitoring the traffic very closely with tcpdump on the
interface and not the log.
Unless you have an explicit need to block in/out, it's easier to
maintain a ruleset that uses
block log on $ext_if
For example, I use the following as a "starting point" for some of my
routing firewalls:
=============================
int_if=bge1
ext_if=bge0
set skip on lo
# block everything
block
# NAT rule
pass out log(all) on $ext_if from ($int_if:network) to any nat-to ($ext_if)
# allow traffic in on the internal interface
pass in on $int_if from ($int_if:network) to any keep state
=============================
There are at least three things in that basic config that some people
would jump on me for.
1) why block all if I'm then allowing every in on the internal interface?
2) why block all if I'm allowing everything out on the external interface?
3) why not pass everything on the internal interface and then filter
on the external?
The shortest answer is because I happen to like that starting point
and it serves as a syntactical reminder if I deploy without a pf
reference handy.
Regarding 1) and 2), the longer answer is that I like to control
traffic flow. I don't want to allow inbound connections on the
external interface and I don't have a need for the firewall to connect
to machines inside the NAT. On my bridges I'll set skip on the
internal interface and filter on the other but I don't like doing that
for a router.
No jumping here- just a big fat ditto!
But that was the point of this whole thread- that block statement
doesn't cut it. I started there and noticed a little sneak getting
through anyway. Set it to the block explicitly and bam! No problem. Just
a little heads up anyway...
There are some plans to update PF to a more recent version. So may
be it will be better.
Actually, that sounds like a better idea than mine ;) Kills 2 birds with one
stone then...
I am truly excited about this as the NAT and RDR stuff was
significantly cleaned up (and the OpenBSD pf FAQ is a great resource).
I'm even more excited about the patch to tcpdump that Daniel just sent
to freebsd-pf@ that allows you to tcpdump a pfsync device and pull the
state creation/updates - in my opinion, that's the weakest area for a
BSD firewall (we'll ignore span ports on routers since you can bridge
two addressed interfaces and create a span of that bridge) and being
able to easily pull those NAT translations fulfills some serious
accountability issues.
You think?! Man I was scratching a bit trying to translate between
versions there- not too long, but long enough to a PITA. It would be
nice to have it all nice and tidy...
If you need a reliable printed reference, you should really consider
picking up Hansteen's _The Book of PF_, available from No Starch
Press:
http://nostarch.com/pf2.htm
I have the first edition and it's incredible but somewhat dated. The
author suggests the second edition for FreeBSD 8.x+.
kmw
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
