Full path to the policy compiler executable. Use this if you do not want to use standard Firewall Builder policy compiler that comes with the package or if you want to wrap compiler in a script.
Additional command line options for the policy compiler.
Specify the name of the generated iptables script. If left blank, the file name is constructed from the firewall object name and extension ".fw".
Generated script will be copied to the firewall using this name. Can be full absolute path as well.
Installation process is controlled by several variables that the user can change in the "advanced" dialog for the firewall platform:
Tab "Compiler":
These variables have default values if input fields are left blank in the dialog:
Output file name: the name of the firewall object, plus extension ".fw".
Script name on the firewall: the same as the output file name
directory on the firewall: "/etc" (tab "Installer")
command that installer executes to activate policy: installer runs script <firewall>.fw
If user enters alternative name in the "script name on the firewall", it is used when generated script is copied to the firewall. There are two input fields in the dialogs for PF and ipf where user can enter alternative name for the .fw script and .conf file. The name can be relative or absolute path. If it is a relative path or just a file name, it is treated as a file name in the directory specified by the "directory on the firewall" input field in the "Installer" tab. If the name is an absolute path, the directory entered in "directory on the firewall..." input field is ignored. If user entered alternative name for the script on the firewall, the command that installer should execute to activate it must be entered as well. If the alternative name was entered as an absolute path, activation command should take this into account and use the same absolute path. The command can start with "sudo " if user account used to copy and activate policy is not root.
If this option is ON, the firewall will accept TCP sessions opened before the firewall software has been activated. These sessions are special because the firewall never saw their initiation phase. If this option is on, the firewall creates an entry in the state table when it sees a packet that apparently belongs to the unknown TCP session.
For PF 4.x this option adds "flags any" parameters to rules that match TCP services. PF 4.x by default behaves as if "flags S/SA" parameter was added to all rules matching TCP services. Adding "flags any" makes rule match not only TCP packets with SYN flag set and ACK flag cleared, which is the packet that initiates the session, but also packets with any other combination of flags, including just ACK flag set. Firewall will see packets like that when session opened before firewall software was restarted and session table cleared hit it.
for PF 3.x the behavior of the policy compiler is opposite: when this option is not set, it adds "flags S/SA" to all rules that match any TCP services; if this option is set, "flags" parameter is not added to these rules at all, which makes them match TCP packets with any combination of flags.
This adds "modulate state" parameter to rules that match any TCP services. Quoting man pf.conf(5), section STATE MODULATION:
Much of the security derived from TCP is attributable to how well the initial sequence numbers (ISNs) are chosen. Some popular stack implementations choose very poor ISNs and thus are normally susceptible to ISN prediction exploits. By applying a modulate state rule to a TCP connection, pf(4) will create a high quality random sequence number for each connection endpoint.The modulate state directive implicitly keeps state on the rule and is only applicable to TCP connections.
For instance:
block all pass out proto tcp from any to any modulate state pass in proto tcp from any to any port 25 flags S/SFRA modulate stateNote that modulated connections will not recover when the state table is lost (firewall reboot, flushing the state table, etc...). pf(4) will not be able to infer a connection again after the state table flushes the connection's modulator. When the state is lost, the connection may be left dangling until the respective endpoints time out the connection. It is possible on a fast local network for the endpoints to start an ACK storm while trying to resynchronize after the loss of the modulator. The default flags settings (or a more strict equivalent) should be used on modulate state rules to prevent ACK storms.
Rule shadowing happens when a certain rule is a super-set of a subsequent rule and any packets potentially matched by the subsequent rule have already been matched by the prior rule. For example, if rule #1 uses the network object for the source and rule #2 uses the host object located on that network for the source, rule #1 ’shadows’ rule #2 because any packet matched by #1 will never be matched by #2. This may be important if, say, rule #1 permits and #2 denies access to the same destination. If rule #1 ’shadows’ rule #2, then rule #2 will never fire. This situation is most often an error; the compiler can detect it and abort processing of the policy with an appropriate error message.
Compiler supports special case when empty group is used in the policy rule and there are no other objects in the same rule element. Depending on the state of this option, it generates iptables commands as follows:
This is useful when one needs to control access to/from a group of hosts which may change and sometimes becomes empty. When this option is turned on, compiler will automatically disable the rule if the group becomes empty. Group contents can be managed manually or by a script using fwbedit command line tool.
When this option is checked, compiler adds rules to permit ssh
access to the firewall from the specified address block. Rules are
placed at the very beginning of the policy to make sure ssh access
is permitted even if there is an error in the policy which otherwise
would block it. Added rules permit packets that match both NEW and
ESTABLISHED states to avoid breaking ssh sessions that were already
established.
Compiler adds rules "scrub in all [options]" and
"scrub out all [options]" at the top of generated
pf.conf file. This dialog tab controls options added to this rule.
Translates into "scrub out all no-df"
From man pf.conf(5):
Unfortunately some operating systems also generate their dont-
fragment packets with a zero IP identification field. Clearing
the dont-fragment bit on packets with a zero IP ID may cause
deleterious results if an upstream router later fragments the
packet. Using the random-id modifier (see below) is recommended
in combination with the no-df modifier to ensure unique IP
identifiers.
Tab Scrub rule options
Clear DF bit
Clears the dont-fragment bit from a matching IP packet. Some
operating systems are known to generate fragmented packets with
the dont-fragment bit set. This is particularly true with NFS.
Scrub will drop such fragmented dont-fragment packets unless no-df
is specified.
This option is only used with scrub out all rule and therefore applies to all packets sent or forwarded by the firewall.
Translates into "scrub out all random-id"
From man pf.conf(5):
Replaces the IP identification field with random values to compensate for predictable values generated by many hosts. This option only applies to packets that are not fragmented after the optional fragment reassembly.
This option is only used with scrub out all rule and therefore applies to all packets sent or forwarded by the firewall.
Translates into "scrub out all min-ttl"
From man pf.conf(5):
Enforces a minimum TTL for matching IP packets.
This option is only used with scrub out all rule and therefore applies to all packets sent or forwarded by the firewall.
Translates into "scrub out all max-mss"
From man pf.conf(5):
Enforces a maximum MSS for matching TCP packets.
This option is only used with scrub out all rule and therefore applies to all packets sent or forwarded by the firewall.
Enables the following three options that control fragment reassembly options.
Translates into "scrub in all fragment reassemble"
From man pf.conf(5):
Using scrub rules, fragments can be reassembled by normalization. In this case, fragments are buffered until they form a complete packet, and only the completed packet is passed on to the filter. The advantage is that filter rules have to deal only with complete packets, and can ignore fragments. The drawback of caching fragments is the additional memory cost. But the full reassembly method is the only method that currently works with NAT. This is the default behavior of a scrub rule if no fragmentation modifier is supplied.
This option is only used with scrub in all rule.
Translates into "scrub in all fragment crop"
From man pf.conf(5):
The default fragment reassembly method is expensive, hence the option to crop is provided. In this case, pf(4) will track the fragments and cache a small range descriptor. Duplicate fragments are dropped and overlaps are cropped. Thus data will only occur once on the wire with ambiguities resolving to the first occurrence. Unlike the fragment reassemble modifier, fragments are not buffered, they are passed as soon as they are received. The fragment crop reassembly mechanism does not yet work with NAT.
This option is only used with scrub in all rule.
Translates into "scrub in all fragment drop-ovl"
From man pf.conf(5):
This option is similar to the fragment crop modifier except that all overlapping or duplicate fragments will be dropped, and all further corresponding fragments will be dropped as well.
This option is only used with scrub in all rule.
Compiler adds rule "set limit [options]" at the top of generated pf.conf file. This dialog tab controls options added to this rule.
Translates into "set limit frags NNN"
From man pf.conf(5):
Sets the maximum number of entries in the memory pool used for fragment reassembly (generated by scrub rules)
Translates into "set limit states"
From man pf.conf(5):
Sets the maximum number of entries in the memory pool used by state table entries (generated by pass rules which do not specify no state).
Translates into "set limit src-nodes"
From man pf.conf(5):
Sets the maximum number of entries in the memory pool used for tracking source IP addresses (generated by the sticky-address and src.track options)
Translates into "set limit tables"
From man pf.conf(5):
Sets limits on the memory pools used by tables. "set limit tables" sets the number of tables that can exist.
Translates into "set limit table-entries"
From man pf.conf(5):
Sets limits on the memory pools used by tables. "set limit tables-entries" sets the number of addresses that can be stored in tables.
Compiler adds rule "set timeout [options]" at the top
of generated pf.conf file. This dialog tab controls options added to
this rule. See man pf.conf(5) for explanation.
Installer will try to put generated script in /etc on the firewall,
unless this option specify different location
This can be root or any regular user name. See "How to use built-in policy installer" on the web site at http://www.fwbuilder.org/guides/firewall_builder_howtos.html
Normally installer uses address of the interface marked as
"management" to communicate with the firewall. Note that installer
uses IP address rather than run DNS query for its name. You can
specify different IP address in this option if necessary.
If this option is blank, installer copies script produces by the
policy compiler to the firewall and executes it there. If this
option defines different command, installer copies generated script
and then runs this command.
This can be useful if you want to use alternative port for the ssh
session to the firewall. Just put "-p PORT" here and this option
will be appended to the ssh command line.
Put the full path to your own installer script here if you have one.
Add commands that you want compiler to insert into generated script
here. Prolog section is added at the beginning of the script, before
generated iptables commands. Note that generated iptables script is
just a shell script, so commands you place in the Prolog and Epilog
sections should be valid Bourne shell commands.
Epilog commands are added at the bottom of generated script, after
iptables commands.
this translates into "label
Compiler adds policy rule at the bottom of the pf rule set that just
denies all packets in and out. This is just a fallback rule that
follows best practices in firewall policy design. Normally this rule
blocks but does not log packets. This option makes it log.
This option makes the generated firewall script print all commands
when it is executed. To do this, compiler adds "-x" to the shell
command line at the top of the script. Command pfctlc/ used to
load PF rules into the kernel will also be given command line flag
"-v".
This option makes compiler add commands to configure IP addresses of
the interfaces of the firewall according to the "Address" objects
added to interfaces in the Firewall Builder GUI.
The compiler can generate commands to add a virtual address to one
of the interfaces of the firewall machine if this option is turned
on. This is needed if a NAT rule uses an IP address that does not
belong to any interface of the firewall. The firewall either needs
the static ’published’ ARP entry for this address, or it should be
added to one of the interfaces as an ’alias’ or virtual address.
The policy compiler adds code to add an ’alias’ address to the
interface on top of the firewall activation script.
Compiler can add command "pfctl -F states" after command "pfctl -f
file.conf" to flush states that existed in memory from sessions
opened prior to the policy reload. The reason is that some of these
sessions might be denied by the new policy, but if state is not
flushed, they will still work after the policy has been
reloaded. This is optional and is off by default.
Note that ssh session used by the built-in installer to upload new
pf configuration and activate it on the firewall is also subject to
the state tracking and can hang if state is flushed. However,
command added by the policy compiler when option "Always permit ssh
access from the management station with given address" is used is
immune to this. This command is written in a such way that firewall
will automatically restore the state used to track ssh session
opened by the installer so it will never hang. This option is
located in the tab "Compiler" of the same dialog.
Compiler can place ipv6 policies before or after ipv4 rules. This
option controls the order.
Tab Installer
Directory on the firewall where script should be installed
User name used to authenticate to the firewall
Alternative name or address used to communicate with the firewall
Command that installer should execute on the firewall to activate the policy
Additional command line parameters to ssh
External policy install script
Command line options for the script
Prolog section
Epilog section
Tab Logging
Log Prefix:
Fallback "deny all" rule should log blocked packets
Tab Script Options
Turn debugging on in generated script
Configure interfaces of the firewall machine
Add virtual addresses for NAT
Flush pf states after reloading rules
Tab IPv6
Order in which IPv4 and IPv6 rules should be generated