Sorry, gorgot a basic rule!
Il 23/07/2012 13:26, Tonix (Antonio Nati) ha scritto:
Il 23/07/2012 13:13, Daniel Hartmeier ha scritto:
On Mon, Jul 23, 2012 at 12:53:41PM +0200, Tonix (Antonio Nati) wrote:
So, does that mean the OUT phase evaluation always occurs when IN phase
has been positive (packet should pass)?
Yes. You have to both allow a packet in on the first interface and out
on the second interface. If you forget/omit the second part, the packet
will get dropped (assuming a default block policy).
I'm thinking to management of a lot of interfaces, where one is the WAN,
and others are DMZ and/or customers dedicated subnets.
I'd love to put basic protections on WAN input, and then permit all
other interfaces to define its own rules for packets coming/going
from/to the specific subnet.
According to what I understand of your explanation, each interface could
have its own IN rules, and if the IN rules of a specific INPUT interface
are successfull, the OUT rules of the 'outgoing' interface are then
evaluated.
Yes. Example: you want to prevent customers from talking to arbitrary
SMTP hosts (prevent spam by forcing the use of a spam filtering proxy).
You can block this with OUT rules on the WAN interface, i.e. by only
allowing the proxy's source address to connect to external hosts'
port 25.
Even if customers can add pass rules for their respective interfaces,
they cannot circumvent your OUT on WAN rules.
This would be wonderful, as each interface could have both IN and OUT
rules which do not interphere with or break other interfaces rules. And
would permit to write the most of rules just once, according to each
interface needs.
Yes, that's the upside of filtering on both directions on all involved
interfaces :)
The downside is that you might have to add some redundancy in your
rules: even if a customer adds 'pass out on DMZ to port 80' you'll also
have to add 'pass out on WAN to port 80'. When a customer complains that
something isn't working, you'll have to check both his interface's rules
AND the WAN rules.
I have customers which should be allowed to go whetever they like and
accept from all.
So I'd love to make something like this:
- deny on INPUT WAN from hackers/abusers
- allow any other INPUT on WAN
- allow any OUTPUT to WAN
- custom INPUT rules on all other interfaces
- custom OUT rules on all other interfaces
So, if a customer wants to allow anyone to access his port 80, he/she
just add that OUT rule to his/her interface. And that avoids me to add
the same rule to WAN and all remaining interfaces.
Respect to the dominant model (i.e. which puts any rules on INPUT only),
do you see any security hole? Or just some more processing?
Regards,
Tonino
--
------------------------------------------------------------
Inter@zioni Interazioni di Antonio Nati
http://www.interazioni.it [email protected]
------------------------------------------------------------
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[email protected]"