Interface Direction (and why it's important to me)



  • Gracious peers,

    My understanding is that all pfsense FW rules for an interface apply to packets coming inbound to the interface. That's certainly how ours behaves. If I am muffing this, please ignore the following misinformed self-righteous drivel.

    There are two primary issues I'm having with inbound-only rules:

    1. It prevents filtering at a single choke-point.

    The idea of firewalling is to enforce a policy of some kind on traffic to and from a network. A firewall is a choke-point device between networks, and the external interface is the choke-point for the protected networks. The current pfsense does not allow enforcement of a policy for both inbound and outbound traffic on a single choke-point interface.

    This complicates the rulebase, because it requires rules on multiple interfaces where one would do. Specifically, to determine/restrict the traffic allowed TO a particular host, the rulebases for every_other_interface must be reviewed/configured.

    Examples:

    • Block all snmp and SMB outbound on WAN interface (requires rules on all other interfaces, instead of one on WAN)

    • Block all traffic to bogons on WAN interface (requires rules on all other interfaces, instead of one on WAN)

    • Block all ICMP to a a server on a DMZ on an OPT interface (requires rules on all other interfaces, instead of one on WAN)

    • Allow access to a service from certain specific hosts on specific subnets (requires different rules on each other interface)

    This is needlessly complex, and leaves opportunity for variation and omission. It's particularly troublesome on the WAN interface, for which it would be nice to be able to define and view what the firewall as a whole will allow outbound.

    2. It can't restrict VPN traffic
    Since VPN traffic is decrypted after it traverses the inbound firewall ruleset, the unencrypted packets don't ever come inbound on any interface, making them unfilterable.

    The only solution I've come upon here is to firewall inbound at the VPN peer This is unwieldy and bad security practice at best, impossible at worst (if you don't manage the VPN peer)

    The intersection of these two issues for us is that

    • it is very difficult to do any centralized internal control of network traffic

    • t is very difficult to manage our "absolute" inbound and outbound policies.

    If you have way about this, I would be grateful to share in your insight.

    What pfsense features would solve this
    –-----------------------------------------------------

    • A checkbox somewhere to enable directional rules

    • Once checked, interface direction would be available in rules, (defaulting to inbound)

    • Icons would be displayed to indicate interface direction. Something fairly intuitive, like an arrow pointing to a door, for inbound, an arrow pointing away for outbound.

    Has anything in this wise been considered? I see this as a very basic feature of any modern firewall, and much more central to its function than a broader (admittedly fantastic and prodigious) feature set.

    Thanks,

    michael



  • #2 is not an issue in HEAD.

    #1 is not something that I plan on even looking at.  You may want to take a look at this thread:
        http://article.gmane.org/gmane.comp.security.firewalls.pfsense.support/6479



  • Actually for #2 - as scott mentioned, not an issue in HEAD - filtering outbound for incoming VPN traffic is a bad idea and rather than implement a broken workaround and allow that, we opted to wait until we could filter INBOUND on VPN.  This now allows us to protect the firewall itself (what a concept!).  Also, we're a default block environment (except for the default 'idiot' rule we install on lan that can be removed) - why are you allowing traffic into your firewall you don't want it to pass?  Seems like you're trying to follow a default allow, block what I don't like policy - that's certainly not a best practice.

    –Bill



  • @sullrich:

    #1 is not something that I plan on even looking at.  You may want to take a look at this thread:
        http://article.gmane.org/gmane.comp.security.firewalls.pfsense.support/6479

    I read that thread, and the main points i got from it were:

    1. Some guy thought firewall policies should not require choice of interface from user, and the firewall should automate all of that based on its knowledge of attached networks and interfaces.
    2. A number of other people (some who seem to have extensive FW and customer experience), believe that

    • this limits and obfuscates the actual operation of the firewall

    • the full capability of the underlying kernel firewall and the nuance of the rulebase should be available, and in the hands of the admin, not a parsing engine.

    I feel the point I'm trying to make is in concert with the folks from number 2, giving the admin granular control over the operation of the firewall. What that what you hoped I would get out of it?

    @billm:

    Actually for #2 - as scott mentioned, not an issue in HEAD

    That's pretty cool. when can we expect that in release code?

    @billm:

    filtering outbound for incoming VPN traffic is a bad idea and rather than implement a broken workaround and allow that, we opted to wait until we could filter INBOUND on VPN.

    Sure, but in the current situation there is no filtering on VPN, which makes pfsense unsuitable for extranet VPN, and less secure and less manageable. And i'm not sure what broken workaround you're referring to. I'm suggesting providing the interface direction inherent in pf to the admin in the GUI.

    @billm:

    Also, we're a default block environment (except for the default 'idiot' rule we install on lan that can be removed) - why are you allowing traffic into your firewall you don't want it to pass?  Seems like you're trying to follow a default allow, block what I don't like policy - that's certainly not a best practice.
    –Bill

    The problem I have currently is that pfsense is a default allow environment–outbound from every interface--and I can't even block what I don't like because I can't make rules for it.

    For years, I managed an ipf firewall on netbsd, on a five-interfaced sparc5. We enforced every security policy both inbound and outbound on every interface (all default deny). I consider that the best practice from a security standpoint, because it's likely to be most restrictive, and to limit the security impact of a ruleset error. I can't set a default deny outbound into my subnets with pfsense.

    Bill, Sullrich, gracious readers, please indulge me in a little story:

    The Story:
    A courtyard (fw ip stack) is fully enclosed between two buildings (networks). Each building has a single door (interface)  to the courtyard with a security guard (fw). The guard thoroughly checks the identification and destination of all entities leaving the building against an access list (fw ruleset), but allows anyone to enter. Note that:

    • The security for entering building A is enforced at the door of building B

    • The security for entering building B is enforced at the door of building A

    It seems logically odd that, to see what is allowed into building A, you need to look at the list at building B. The courtyard has great access control, though.

    Let's look at a courtyard of n buildings. To enforce a security policy to keep specific entities from entering a building, we need n-1 rules, one for each building other than the one we are restricting access to–if we could restrict entry into the building, we would need only 1.

    If we have four buildings, and want to have four policies for access to each building, we are looking at 48 individual rules:

    • 1 policies  = 3 rules

    • 4 policies/building = 12 rules

    • 4 buildings = 48 rules

    If we allowed the guards to check entities entering the building, we would have 16 rules instead:

    • 1 policies = 1 rule

    • 4 policies/building = 4 rules/building

    • 4 buildings = 16

    In this last case, we don't have a lot of info about the entities in the courtyard. In the case of internal networks (buildings, whatever), this may be less of a concern, because we may have some measure of knowledge/control over the areas. Best practice, of course, would be to enforce in both locations, and that possibility would pe provided by interface direction.

    Real World Example:
    I have three internal subnets from which I want to limit access to a web server on a network containing other webservers. Current policy allows all subnets web access to all hosts on the subnet, which is amply secure for our general purpose.

    • Inbound rules only: 3 rules; 3 possibilities of error by fatfinger, and 3 places I have to make changes to maintain it

    • Outbound rules allowed: 1 rule; 1 chance for error, 1 location to maintain; no appreciable loss in firewall security since all internal hosts can route lots of stuff through it anyway.

    My points, summarized

    • Interface directionality is a useful aspect of pf that should be available to a firewall administrator

    • There are legitimate firewall approaches using both outbound and inbound filtering, and they should be available in pfsense

    • Outbound rules can be used to reduce the number of firewall rules, with benefits of reduced maintenance, and reduced complexity, both of which may benefit security

    Or, if you prefer them as questions:
    1. Do you think pf should not have the the capability to filter in both interface directions? Should that capability of the underlying firewall be denied in pfsense?
    2. Is there no security benefit in restricting traffic both entering and leaving an interface? Should pfsense determine a single "best practice" paradigm for firewalling, or allow an admin to decide?
    3. Is kernel exposure the greatest threat in firewalling? Might rulebase complexity, manageability, and maintenance issues also be important?

    I beg your pardon if this is a big chunk, but I have tried to be thoughtful and appreciate the opportunity to express my fool opinion.



  • I think Microsoft ISA Server does what you want.
    Give that a go.



  • @Gitsum:

    I think Microsoft ISA Server does what you want.
    Give that a go.

    This remark seems disingenuous, but I will assume it's an honest suggestion and address it as such.

    I have run ISA server 2000 as a proxy server (and in its previous incarnation, MS Proxy Server). It's great as a proxy server in a windows environment because of its integration with windows domains, exchange, and IIS. It's got some huge problems for me as a firewall/VPN endpoint for our purposes though (with apologies to ISA2004, with which I am unfamiliar):

    1. Disturbingly obtuse and scattered user interface
    2. Licensing costs
    3. Runs on windows
    a. Licensing costs
    b. OS maintenance labor
    c. OS resource consumption
    4. High system requirements
      a. Equipment costs
      b. Poor choice for fanless boxes
    5. IPSEC implementation challenges.

    It certainly does not address the specific issue I raised:per-interface directionality of rules.

    I thought I was being clear with what I want, but I'll try to make it even clearer: I want pfsense to support the full capabilites of the underlying pf firewall. My next-best choice is probably going to be to build an embedded Open- or NetBSD, run pf and the pfw GUI, and build the IPSEC configurations manually.



  • @Voami:

    I thought I was being clear with what I want, but I'll try to make it even clearer: I want pfsense to support the full capabilites of the underlying pf firewall. My next-best choice is probably going to be to build an embedded Open- or NetBSD, run pf and the pfw GUI, and build the IPSEC configurations manually.

    Patches accepted!



  • sullrich did you receive any patches? (or is anyone aware of one)

    If not could yo please give me an idea of the work load need to make one. Are we talking hours, days or even weeks of coding?

    I'm looking for alternatives to pf + pfw because pfsense does 99% of what we need while pf + pfw does only 10%. (even if pfw handles 100% of pf options)

    The only missing options is directional rules. As an ISP with 10's of corporate clients I do need a simpler rules set.

    I'm novice in PHP but I did some coding in Perl so I should be able to make a patch. I did not look under the hood si I dont know what making a patch of this magnitudes implies

    -Pat



  • @Waps:

    sullrich did you receive any patches? (or is anyone aware of one)

    No.



  • Hi
    Would just like to add my 2 cents here.

    I also fully believe that outbound filtering is important, and I'd like to see the capability here.
    For a start it would allow enforcement of banned/scheduled web sites from a firewall-hosted squid server… It might make load-balancing 2 WAN connections possible for a firewall-hosted squid server...

    pf can do it... How difficult is it to make pfSense support it?  (not being sarky, I really have no idea of the intricacies involved...)

    Thanks
    Steven



  • There is no reason you cannot control a squid server going to the internet now.  Simply control the flow on the incoming interface of pfSense.



  • @sullrich:

    There is no reason you cannot control a squid server going to the internet now.  Simply control the flow on the incoming interface of pfSense.

    I meant a squid server running on the pfSense box itself…


Log in to reply