Anonymous
Anonymous asked in Computers & InternetInternetOther - Internet · 1 decade ago

How do you setup transparent bridging with FreeBSD and PF?

I run a linux vps hosting farm and would like to establish a transparent firewall between them and the world. I heard that you can do this with 3 NIC's , FreeBSD + PF (Packet filter). Does anyone know how?

1 Answer

Relevance
  • 1 decade ago
    Favorite Answer

    Pf as a transparent bridging firewall on FreeBSD 6 and 7

    The Goal:

    A way to transparently protect a set of servers as well as monitor the inbound and outbound traffic to said servers.

    Solution:

    The end solution was to install FreeBSD 6.2 or 7.0 Release on a server and utilize packet filter (pf) as a transparent bridge to meet the IP addressing requirements.

    Howto:

    1.) Install FreeBSD

    We have a checklist list of tasks to perform to install and lock down our production servers. Follow your own best practices to get a basic install of FreeBSD 6.2 or 7.0 running and patched. Install the minimal amount of options and packages necessary.

    You will need, or at least you will most likely want, a third NIC installed in the server. In a transparent bridge the WAN and LAN interfaces become “transparent” and no longer take an IP address. So without the third NIC installed and connected to your network you will have no way to remotely manage the server. A benefit of this though is that without an IP address to attack your transparent bridging firewall itself would be free from attack.

    Pf is available in a default install by re-compiling the kernel with specific changes made, or by enabling pf via kernel loadable module.

    We re-compiled the kernel. The options below were added at the end of the kernel source and the new kernel compiled:

    # pf support

    device pf # Packet Filter firewall

    device pflog # PF logging facility

    device pfsync # PF state syncing

    # ALTQ support

    options ALTQ

    options ALTQ_CBQ

    options ALTQ_RED

    options ALTQ_RIO

    options ALTQ_HFSC

    options ALTQ_PRIQ

    2.) Configure your third NIC with an IP address and verify you can remotely access your server.

    In the /etc/rc.conf file we have the following definition for the management IF:

    ifconfig_fxp0=”inet 123.123.123.2 netmask 255.255.255.0″

    We will be building pf rules for this NIC as well to protect the firewall itself.

    3.) Create the bridge between the two desired interfaces.

    Use your favorite editor to edit /etc/rc.conf and enable the bridge

    Add:

    cloned_interfaces=”bridge0″

    ifconfig_bridge0=”addm bge0 addm nfe0 up”

    ifconfig_bge0=”up”

    ifconfig_nfe0=”up”

    In this case we are bridging the two interfaces bge0 and nfe0.

    Use your favorite editor to edit /etc/sysctl.conf

    Add:

    net.link.bridge.pfil_onlyip=1

    net.link.bridge.pfil_member=1

    net.link.bridge.pfil_bridge=0

    4.) Enable the use of pf on your server.

    Use your favorite editor to edit /etc/rc.conf and enable the use of pf

    Add:

    pf_enable=”YES” # enable PF (load module if required)

    pf_rules=”/etc/pf-bridge.conf” # rules definition file for pf

    pf_flags=”" # additional flags for pfctl startup

    pflog_enable=”YES” # start pflogd(8)

    pflog_logfile=”/var/log/pflog” # where pflogd should store the logfile

    pflog_flags=”" # additional flags for pflogd startup

    5.) Build the firewall ruleset.

    First make a copy of the default ruleset and designate it as a bridging ruleset.

    # cp /etc/pf.conf /etc/pf-bridge.conf

    Use your favorite editor to edit /etc/pf-bridge.conf. Place your ruleset within the pf-bridge.conf file and save the changes.

    Here is the sample ruleset: pf-bridge_generic.txt

    6.) Apply the rules and enable the firewall.

    Finally to actually enable a new ruleset we need to tell pf to read the config file. This would also automatically happen upon reboot.

    # pfctl –f /etc/pf-bridge.conf

    # pfctl –e

    Thats it. You will now need to go through and test the bridge and verify you can access what you intended to allow access to, and that what you wanted to block is now blocked. Hopefully you still have access to the management interface as well. The best test will be to perform some form of vulnerability testing against IPs behind your firewall and the firewall itself.

    Some notes on the ruleset specifically:

    - There is really nothing in the ruleset that designates the firewall as a transparent bridge other than the absence of NAT rules. The bridge built in the OS itself in the /etc/rc.conf file is where the bridging is applied. - The IP addresses in the variable and table definitions will obviously have to be updated to fit a different environment. - Many options exist for pf and there are full books dedicated to the art of pf rulesets and using pf in general. This ruleset for example could be expanded to make more use of AltQ for QoS and added protection against DoS attacks.

    • Login to reply the answers
Still have questions? Get your answers by asking now.