Linux Firewall
  >> PROJECT HOMEPAGE

Configuration Options

Note: New users should review the "Conventions" section at the bottom of this page.


Basic Configuration Options
  • The basic configuration options are explained in great detail at beginning of rc.firewall and are configured interactively by the graphical installer. These options include the PERMIT, INTERNAL_INTERFACES, and DYNAMIC_INTERFACES directives.

Advanced Configuration Options
  • DENY_OUTBOUND - {List} Use this directive to block outgoing traffic through a Linux router. Connections attempts matching entries here will be denied.
    Format: [[<source network>[/<mask>]][:<destination network>[/<mask>]:][<ports>[/<protocol>]]
    Simplified Format: [<source network>][:<destination network>][:<ports>]
    Examples:
        DENY_OUTBOUND="192.168.1.123"   Block all outbound traffic from host 192.168.1.123
        DENY_OUTBOUND=":216.35.208.0/24 25/tcp"   Block traffic to IMesh and smtp traffic from anyone (except from networks/hosts specified in PERMIT; see advanced discussion section for more details.)
        DENY_OUTBOUND=":131.107.0.0/16:53"   Block DNS traffic to Microsoft Corporation (Not that it matters, Microsoft outsourced their servers to Akamai)
        DENY_OUTBOUND="192.168.120.150/30:0.0.0.0/2:1-65535/udp"   Block all UDP traffic from 192.168.120.148 through 192.168.120.151 to half the Internet

  • ALLOW_INBOUND - {List} This directive is used to selectively allow traffic into a DMZ -or- allow inbound traffic to an internal host defined in STATIC_INSIDE_OUTSIDE -or- allow traffic through the firewall to internal hosts when you are not doing NAT (internal hosts must have publicly routable addresses). This directive has the same format as DENY_OUTBOUND above.
    Examples:
        ALLOW_INBOUND="66.187.224.0/20"   Permit traffic from Red Hat, Inc. to reach all internal hosts with static routes through the firewall.
        ALLOW_INBOUND=":192.168.10.25:80/tcp"   Permit external hosts to access an internal webserver at 192.168.10.25.

  • BLACKLIST - {List} Packets to or from any host, network, or port listed here will be dropped. This includes inbound, outbound and forwarded connections. This blocking takes presedence over all other configuration preferences. This option has the same syntax as PERMIT explained in the Basic Configuration Section.
    Format: [<host or network address>[/<netmask>]][:[<port or port-range>[/<protocol>]]
    Example:
        BLACKLIST="10.1.1.1"   Block all connections to and from host 10.1.1.1.

  • STATIC_INSIDE_OUTSIDE - {List} This directive is only useful if you have multiple external (public) IP addresses. It is used to create static conduits through the firewall, with the following effect: 1.) Outbound traffic from the given internal network or host is mapped onto a given external address. 2.) If the internal address is a single host, then inbound traffic to the external address is mapped inside the network according to the contents of ALLOW_INBOUND. 3.) If the outside address contains a subnet mask (i.e. represents a network of external addresses) then STATIC_INSIDE_OUTSIDE will map the given external network onto the given internal network, as if each host from the two networks were entered separately. See the advanced documentation for additional information. This option is especially useful to allow hosts behind a NAT firewall to have their own public static IP address.
    Format: <inside network>[/<mask>]:<outside address>[/<mask>]
    Example:
        STATIC_INSIDE_OUTSIDE="192.168.0.12:64.28.67.35"   Source NAT outgoing traffic from 192.168.0.12 to 64.28.57.35. Also forward (DNAT) inbound traffic destined for 64.28.67.35 to 192.168.0.12.

  • PORT_FORWARDS - {List} This directive intelligently forwards connections received on a specific port to a specified host and port. If PORT_FWD_ALL below is disabled, the PERMIT option can be used to allow access to a port forwarding definition. If no protocol is specified, then it is assumed that connections of either protocol should be forwarded. If the destination ports are missing, the inbound port number will not be modified.
    Format:[<protocol>:]<inbound port or port-range>:<destination host>[:<destination port or port-range>]
    Examples:
        PORT_FORWARDS="53:192.168.0.11"   Forward incoming connections on port 53 to 192.168.0.11
        PORT_FORWARDS="tcp:8080-8090:192.168.0.10:80"   Forward incoming tcp connections ports 8080 through 8090 to 192.168.0.10 port 80

  • PORT_FWD_ALL - {yes/no} Enabling this option allows all hosts to use all port forwarding definitions.

  • PORT_FWD_ROUTED_NETWORKS - {yes/no} Enabling this option allows machines inside a firewall (internal and additional routed networks) to use port forwarding definitions.

  • ADDITIONAL_ROUTED_NETWORKS - {List} Some users may wish to allow routing from additional networks besides those directly connected to internal interfaces. This is where to specify such networks. For security reasons, these connections must still originate from an internal interface. Make sure you add a kernel route for these networks!
    Format: <network>[/<mask>]

  • TRUST_ROUTED_NETWORKS - {yes/no} Enabling this option allows machines inside the firewall (internal and additional routed networks) to connect to services on the firewall itself. This does not include DMZ interfaces and is the same as adding your internal and routed networks to the PERMIT directive above. Disable it if you do not wholeheartedly trust the hosts inside the firewall [eg a corporate firewall].

  • SHARED_INTERNAL - {yes/no} The default answer of "yes" allows internal and additional routed networks access to each other. This is how the firewall has historically operated. However in some cases this behavior is not desirable, so this option was added to give administrators the chance to disallow communication between multiple internal networks.

  • FIREWALL_IP - {List} This option is available to those who wish to build a network of hosts with publicly routable address to be protected by a Linux firewall. If you are not dealing with a pool of such addresses, then you can safely ignore this option. Administrators who use this option are encouraged to read this essay entitled Using the Firewall in an ISP Application, and give special attention to the last section where network configuration is described. Note that this option requires routing changes to your next-hop router. This directive takes two addresses separated by a colon. The first address is the private address used on the Linux firewall on the interface connected to the border router. The second address is a publicly routable address which must be configured on a DMZ or internal interface. The firewall will perform NAT on outbound traffic with the first address as a source and change it to the second address in the entry. Multiple entires can be entered for hosts with multiple Internet gateways.
    Format: <private external address>:<public internal address>
    Examples:
        FIREWALL_IP="10.0.0.2:64.28.67.35"   Perform NAT to change the source address of traffic that would otherwise leave the router with the private address 10.0.0.2 to the public address 64.28.67.35 which is configured on a DMZ or internal interface.

  • TRUST_LOCAL_EXTERNAL_NETWORKS - {yes/no} Many times local networks attached to external interfaces can be trusted. Enabling this option will trust local external networks as if you had added them to the PERMIT directive. This might be useful for a mobile system which is frequently transported from one trusted network to another. This way firewall settings do not need to be adjusted for each network (though the firewall does need to be run again so that it can recognize its new location and configure itself accordingly).

  • DMZ_INTERFACES - {List} DMZ interfaces are treated as internal interfaces except that NAT rules are *not* applied. This applies to both inbound and outbound connections. Note that by default all inbound connections from non-internal interfaces are blocked and must be opened using the ALLOW_INBOUND directive if you wish to permit inbound traffic from the Internet.

  • NAT_EXTERNAL - {yes/no} This option will tell the router to perform NAT on all connections outbound EXTERNAL interfaces. Enabling this option is the equivalent of manually adding each your external interfaces to the "ADDITIONAL_NAT_INTERFACES" directive below.

  • ADDITIONAL_NAT_INTERFACES - {List} List of additional interfaces besides those automatically selected by NAT_EXTERNAL through which to NAT outbound connections. This option is provided separately in order to give finer control over where NAT is used.
    Example:
        ADDITIONAL_NAT_INTERFACES="eth3"

  • IGNORE_INTERFACES - {List} This is a special option for systems with special interfaces that cause problems with firewall execution.
    Example:
        IGNORE_INTERFACES="nas0"

  • LOGGING - {yes/no} This option enables logging of connections blocked by the firewall, excluding broadcast traffic. The script limits the number of log entries that can be generated in a given period of time in order to prevent denial of service by means of filling up your logs. Unfortunately this means that it is possible that all denied traffic will not be logged. This option will also log what appear to be imcp floods. Enabling tcp_syncookies can reduce the effects of a DoS attack. Since most people will never use the cryptic kernel logs that this option generates, it should be safe to leave it off.

  • REQUIRE_EXTERNAL_CONFIG - {yes/no} Setting this option to 'yes' will force the firewall to load data from an external configuration file. If none is specified on the command line (see the advanced documentation for details) then the default '/etc/firewall.conf' is used. If an external configuration file cannot be found, the firewall will print a failure message and exit. Currently there is very little application for this option, so it is safe to leave it as "no".
Advanced Firewall Behavior Options   (a.k.a. really-really advanced options)
  • NO_RP_FILTER_INTERFACES - {List} DISABLE kernel level reverse path filtering on interfaces listed in this directive. This option is discussed in greater detail in the advanced discussion section.
    Example:
        NO_RP_FILTER_INTERFACES="ipsec0"

  • INTERNAL_DHCP - {yes/no} Since DHCP clients do not have a source address when connecting to a DHCP server, there is no way to tell if they are part of the internal network. Enabling this option tells the router to accepts all DHCP requests received on an internal interface.

  • RFC_1122_COMPLIANT - {yes/no} This option toggles your position on a hotly debated topic in Internet security. Leaving this option set to 'yes' (as it is by default) configures your machine to behave ``correctly'' on the information superhighway by responding to ICMP-ECHO-REQUEST packets (pings) as well as sending ICMP-PORT-UNREACHABLE packets when a host tries to connect to a service that either does not exist or is blocked by the firewall (without differentiating between the two). Before disabling this feature please read this section: Port Security for Newbies.

  • DROP_NEW_WITHOUT_SYN - {yes/no} By default netfilter classifies tcp packets without the SYN flag set but not part of an existing session, as state "NEW". In many cases these packets should really be considered INVALID, but this behavior would have a few critical consequences. Apparently some applications *cough Microsoft cough* continue to transmit session related packets after sending a FIN/ACK to tear down the session. This would cause one of those "why the %&#@! is this application not working behind this Linux firewall!" kind of problems that would be extremely difficult to diagnose. Another reason for this default behavior is to allow Linux to support hot failover firewalls which maintain currently established sessions without access to the actual connection tracking information. Currently established connections would never actually make it to the ESTABLISHED state but be allowed to continue due to rules filtering NEW sessions. In other words, the netfilter team really does know what they are doing. The froxentux.net iptables tutorial makes it sound like a bug. Its not... however if your applications follow the tcp protocol correctly and you do not have a hot failover firewall then enabling this option will increase the security of your firewall. Just remember that you did so so that when some user comes to you complaining that their Microsoft Internet-enabled screensaver program suddenly stopped working, you will know why. :-)

  • DUMP_TCP_ON_INIT - {yes/no} The firewall relies heavily on stateful inspection to decide the fate of passing packets. This method provides an excellent balance between security and usability, but due to the current implementation, connection tracking must be enabled before the firewall is configured. This means current sessions are grandfathered into the ESTABLISHED state even if they would have been blocked as new sessions. In short, running the firewall does not disconnect anyone already connected no matter where they are coming from. Linux Firewall Project beautiful hack #283 "DUMP_TCP_ON_INIT" adds a few temporary rules to reset currently established connections by responding to any incoming data with a tcp packet with the RST flag set. Use [./rc.firewall cleanup] to remove these temporary rules once you feel secure that all the evil crackers connected to your machine have been expelled. The cleanup step is not critical, and is not required at all if you do not dump any connections (the firewall will tell you how many sessions it is dropping). Theoretically the default timeout for an established connections is five days, but with tcp_keepalive enabled on either side of the connection, any keepalive packet (or a response to one we generated) will be met with a tcp reset. So you can safely do a [./rc.firewall cleanup after whatever your tcp_keepalive_time is set to or five days, whichever is shorter. You can have fun with this option by running your firewall via ssh and watching your session be "reset by peer".

  • TTL_STEALTH_ROUTER - {yes/no} Here is another option you won't find anywhere else. If your ISP has crack professionals seeking out "illegal" routers on their network, they can pinpoint suspicious machines by looking at the "time to live" field in the IP headers of packets hitting their routers. Packets that hit an additional router are going to have a TTL field one less than everyone else's and will stand out like soar thumb. This option increments the TTL field on forwarded packets. Unfortunately you cannot do this on a vanilla Linux kernel so you will need this kernel patch script. It is a repackage of the netfilter patch-o-matic base/TTL.patch. You then must enable "TTL target support" (CONFIG_IP_NF_TARGET_TTL, not to be confused with CONFIG_IP_NF_MATCH_TTL "TTL match support") and recompile your kernel. You need 2.4.18+ and some relatively recent version of the iptables userspace tools. Obviously this option is meant for advanced users.

  • LOG_LIMIT - {Rate} This option is used to limit how fast messages are logged via syslog for each of 5 different methods of logging. tcp, udp, icmp, icmp floods, and packets drops from the DROP_NEW_WITHOUT_SYN option. Logging preference options are only consulted if the LOGGING option above is enabled. Also note that no sanity checking is performed on the contents of these parameters. You are expected to know the netfilter syntax to use them. [default: "1/minute"]

  • LOG_BURST - {Rate} Number of log entries allowed before the above rate is applied. [default "5"]

  • LOG_LEVEL - {Level} Syslog log level for firewall logging. [default "5"]

    Conventions   (advanced users can skip this section)
    • All lists are delimited by single spaces.
    • Optional parameters are enclosed in brackets (e.g. [<optional>]).
    • In all {yes/no} directives, 'no' is considered to be anything other than the string 'yes'.
    • <ports> indicates a single port or a dash (-) separated range of ports between 1 to 65535.
    • <protocol> is either 'tcp' or 'udp'. If the protocol is left off, then the firewall assumes either protocol is valid.
    • <network> indicates a network definition in dotted decimal format (i.e. 192.168.0.123). This option can always be appended by a network mask between /0 (all hosts; equivalent to netmask 0.0.0.0 in dotted decimal format) and /32 (a single host; equivalent to netmask 255.255.255.255 in dotted decimal format). If a mask is not specified, then /32 (a single host) is assumed.
      EXAMPLE: The class 'C' network 192.168.10.0 netmask 255.255.255.0 is denoted by 192.168.10.0/24.
    • <address> or <host> is a single IP address in dotted decimal format.
    • <interface> denotes a single interface such as ppp0, eth0, or eth1.


    [ Viewable with any browser ] [ Valid HTML 4.01 ] [ Written in vi ]