Due to lack of exhaustive answers, I posted same questions on FreeBSD PF
mailing list, and Daniel Hartmeier (which wrote PF) gave very detailed
answers.
See http://lists.freebsd.org/pipermail/freebsd-pf/2012-July/006692.html
for answers.
Regards,
Tonino
Il 04/07/2012 19:46, Tonix (Antonio Nati) ha scritto:
Il 04/07/2012 16:21, Sean Cavanaugh ha scritto:
Once you have an incoming connection (first time) to, let's say from
INT X
to INT Y, dest IP Z, dest port P, will these alternative >rules be
evaluated
in same moment or not?
- Evaluate INPUT on INT X, dest IP Z, dest port P
- Evaluate OUTPUT on INT Y, dest IP Z, dest port P
If the answer is YES, there is no added security risk on preferring
filering rules on OUTPUT interface. Both INPUT and OUTPUT >have same
risks.
If the answer is NOT, please explain where and why INPUT and OUPUT are
evaluated in different phases.
Regards,
Tonino
For full explanation you have to understand how the filtering process
occurs
in entirety
SOURCE-------INPUT Interface -----INPUT rule set -----CPU based
routing rule
set -----OUTPUT rule set ---- OUTPUT Interface -----DESTINATION
The CPU based routing rule set is the area where the firewall is
determining
what interface to send the data out of. Even if you only have a 2
interface
firewall, it will still have to evaluate where it has to go because it
technically can go out either interface. People do use NAT reflection to
send data from inside their networks to the firewall and bounce it back
inside. Because of this they take a bit of processing power to
calculate as
they have to be reviewed by pretty much every rule on the box per state
The interface rule sets are the most simple rules. Either traffic is
allowed
or not. They take very little processing power to accomplish. They act
as a
simple bouncer at a night club.
It is because of this imbalance that it is preferred to do filtering
as low
as possible. For a very simplistic example, lets go for extremely
inflated
numbers. Let's say it takes 1% of the CPU to handle interface rules and
takes 5% of the CPU for routing rules.
If we went for pure routing based rules, we could only run 20 states
before
we are at 100% utilization and start running into contention, whereas
if we
went for interface rules, we could run 100 states before we hit 100%.
The problem with running rule sets on the OUTPUT interface is that you
MUST
then use up the routing rule set resources, meaning you would run into
the
same 20 state limit, even for streams that would hit the OUTPUT interface
and be blocked. You would then literally be wasting resources to do
nothing.
This is why it is preferred to make rules based on INPUT as they will
use as
little resources of the firewall as possible. There are times when people
have no choice but to put rules on the OUTPUT interface but that
should be
an absolute last resort as it will cost resources.
Would you rather but a soda for a dollar or run it thru exchange rates
and
end up paying 5 dollars for a soda? It's your call. Sometimes you're THAT
thirsty.
Thanks for the detailed explanation, but...
There is something I don't understand. Your considerations are based on
having three different steps: INPUT, routing, OUTPUT.
This is possible only if you can execute PF on INPUT interfaces, then
execute routing code, then execute again PF for OUTPUT interfaces.
Looking at PF (Packet filter) manuals, I do not see any kind of
call/ioctl like "examine only INPUT INTERFACE" or any possibility to
execute PF code on only a part of filters rules.
PF manual says PF evaluates every rule found in "pf.conf", and does not
mention any possibility to execute only a part of rules.
So, it looks like INPUT and|or OUTPUT interfaces are evaluated at same
stage, probably after routing (which is not part of PF).
Please let me understand better.
Regards,
Tonino
-Sean
_______________________________________________
List mailing list
[email protected]
http://lists.pfsense.org/mailman/listinfo/list
--
------------------------------------------------------------
Inter@zioni Interazioni di Antonio Nati
http://www.interazioni.it [email protected]
------------------------------------------------------------
_______________________________________________
List mailing list
[email protected]
http://lists.pfsense.org/mailman/listinfo/list
