Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Jul 2012 13:26:49 +0200
From:      "Tonix (Antonio Nati)" <tonix@interazioni.it>
To:        Daniel Hartmeier <daniel@benzedrine.cx>
Cc:        "freebsd-pf@freebsd.org" <freebsd-pf@freebsd.org>
Subject:   Re: Question on packet filter using in and out interfaces
Message-ID:  <500D34F9.5000502@interazioni.it>
In-Reply-To: <20120723111348.GD32530@insomnia.benzedrine.cx>
References:  <500826BD.3070602@interazioni.it> <9EB23F6C23A8B6488E8BCC92A48E83264BB4D26F80@PEMEXMBXVS04.jellyfishnet.co.uk.local> <500AB340.2040405@interazioni.it> <9EB23F6C23A8B6488E8BCC92A48E83264BB4D27241@PEMEXMBXVS04.jellyfishnet.co.uk.local> <500AC91F.9090907@interazioni.it> <20120721182316.GA32530@insomnia.benzedrine.cx> <500D1B57.8080405@interazioni.it> <20120723095509.GB32530@insomnia.benzedrine.cx> <500D2D35.4070608@interazioni.it> <20120723111348.GD32530@insomnia.benzedrine.cx>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

So I'd love to make something like this:

- deny on INPUT WAN from hackers/abusers
- allow any other INPUT on WAN
- custom INPUT rules on remaining interfaces
- custom OUT rules on remaining 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




>
> Daniel
>


-- 
------------------------------------------------------------
         Inter@zioni            Interazioni di Antonio Nati
    http://www.interazioni.it      tonix@interazioni.it
------------------------------------------------------------





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?500D34F9.5000502>