rc.firewall 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 detail at beginning of rc.firewall and are configured interactively by the graphical installer. These options include: PERMIT, INTERNAL_INTERFACES, and DYNAMIC_INTERFACES.

Advanced Configuration Options
  • DENY_OUTBOUND - {List} Use this directive to block outgoing traffic through a Linux router. Connection 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 131.107.*.*
        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 only for the reasons listed below. If your application is not one of the these, then you probably should be using PERMIT.
    1. Selectively allow traffic into a DMZ as configured by DMZ_INTERFACES.
    2. Allow inbound traffic to an single internal host defined in STATIC_INSIDE_OUTSIDE.
    3. Allow traffic through the firewall to internal hosts when you are not doing NAT, i.e. you have changed NAT_EXTERNAL to "no" (in which case internal hosts must have publicly routable addresses).
    This directive has the same format as DENY_OUTBOUND above. Note that this directive has no effect on PORT_FORWARDS.
    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 internal network, provided each network is the same size, as if each address from the two networks was entered separately. See the advanced documentation for additional information. This option is usually used to allow hosts behind a NAT firewall to have their own public static IP address.
    Format: <inside address or network>[/<mask>]:<outside address or network>[/<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.67.35. Also forward (DNAT) inbound traffic destined for 64.28.67.35 to 192.168.0.12.

  • PORT_FORWARDS - {List} This directive 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. Note that by default PORT_FWD_ALL is enabled so allowing access in PERMIT is not necessary. 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 and is the equivalent of adding each inbound port in PORT_FORWARDS to PERMIT.

  • 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. Don't forget to add a route in the kernel routing table 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.

  • SHARED_INTERNAL - {yes/no} The default answer of "yes" allows hosts in internal and additional routed networks to use the firewall as a router in order to access to other internal networks.

  • FIREWALL_IP - {List} This option allows you to use the firewall to protect an network of hosts with public IP addresses without subnetting the network by assigning public IP address(es) to an internal interface of the firewall and private (e.g. 10.x.x.x) address(es) to the public interface. With this option enabled the firewall then rewrites the source address of its own outbound traffic, which would normally have been addressed to the address of the external interface, to the public address of the internal interface, allowing the firewall to access, and be accessed by, the Internet. This requires access to your border router in order to configure this private network between the firewall and the border router, as well as add a route for the internal network through the Linux firewall. This directive takes two addresses separated by a colon. The first address is the private address used on the interface connected to the border router. The second is a publicly routable address which must be configured on a DMZ or internal interface if NAT_EXTERNAL is disabled, either as the base address or as an IP alias. 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} Often 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 network address translation is not done on packets routed through the firewall. This means that hosts in a DMZ must have publicly routable IP addresses. 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 to hosts in the DMZ.

  • NAT_EXTERNAL - {yes/no} This option will tell the router to perform source network address translation (SNAT) for all connections orginating from an internal network outbound an external interface. This allows internal hosts on a private internal network to share a single Internet IP addresses. 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 source NAT outbound connections. This option is provided separately to offer the opportunity to more precisely define interfaces from which we want to SNAT traffic.
    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 and what appear to be ICMP flood attempts. Broadcast traffic is not logged. The script then limits the number of log entries that can be generated according to the LOG variables in the next section in order to prevent denial of service by means of filling up your logs. Unfortunately this means that it is possible that not all denied traffic will be logged. Since a blocked connection is really a success of the firewall and most people will never use the cryptic looking kernel logs that this option generates, it is turned off by default.

  • REQUIRE_EXTERNAL_CONFIG - {yes/no} Setting this option to 'yes' will force the firewall to load data from an external configuration file, by default '/etc/firewall.conf'. If an external configuration file cannot be found, the firewall will print a failure message and exit.

Advanced Firewall Behavior Options

  • NO_RP_FILTER_INTERFACES - {List} DISABLE kernel level reverse path filtering on interfaces listed in this directive.
    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 firewall to accepts all DHCP requests received on an internal interface.

  • RFC_1122_COMPLIANT - {yes/no/depends} As of version 2.0rc11 the default option of this configuration directive is 'depends' which configures the host to respond to ICMP-ECHO-REQUEST packets (pings) and send ICMP-PORT-UNREACHABLE packets in response to connection attempts to services which are not available only if the host is a server, as determined by checking for open ports or port forwards. This behavior can be overridden by setting this option to 'yes' in which case the host will always respond to pings and send ICMP-PORT-UNREACHABLE packets or anything other than 'yes' or 'depends' to never respond to pings or send ICMP-PORT-UNREACHABLE packets. Before version 2.0rc11 this option was set to "yes" by default.

  • 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 most cases these packets should really be considered INVALID, but this behavior would have a few consequences. First, it seems that some applications mistakenly continue to transmit necessary packets after sending a FIN/ACK to tear down the session. Second, it allows Linux to support hot failover firewalls which maintain currently established sessions without access to the actual connection tracking information. In this case a currently established session would be tried against firewall rules as a NEW session and allowed into the ESTABLISHED state if it passes. If all of your applications follow the tcp protocol correctly and you do not have a hot failover firewall you can enable this option for a slightly more preclusive firewall as normally all packets making new connections will have the syn flag set.

  • DUMP_TCP_ON_INIT - {yes/no} The firewall relies heavily on stateful inspection to decide the fate of passing packets. This method usually provides a good 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. This directive 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} This option increments the "time to live" field in the IP headers of passing packets to compensate for the fact that routers decrement the TTL of each passing packet. This will leave you with a router that behaves 'incorrectly' as it will pass packets as if no router had touched them. THIS SHOULD NEVER BE DONE. See warnings below. To enable this option on 2.4 kernels you need to patch your kernel with the netfilter patch-o-matic base/TTL.patch and for all kernels you must enable "TTL target support" (CONFIG_IP_NF_TARGET_TTL, not to be confused with CONFIG_IP_NF_MATCH_TTL "TTL match support").

    A warning from the netfilter team: Setting or incrementing the TTL field can potentially be very dangerous, so it should be avoided at any cost. Don't ever set or increment the value on packets that leave your local network!

    Another warning from the Linux kernel team: [What we are doing] is EXTREMELY DANGEROUS since you can easily create immortal packets that loop forever on the network.

  • 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. Note that no sanity checking is performed on the contents of these parameters which should be in standard netfilter log limiting syntax. [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.