Discussion on DROP vs REJECT targets

Confused by "Filtered" versus "Closed" versus "Stealth" ports? This page takes a look at why you should think twice before listening to those scan-my-computer websites.

• Port Security for Newbies
  
  

Setting up Static Conduits Through the Firewall

1. Add an IP alias on the approprate external interface with the public address you wish to use for STATIC_INSIDE_OUTSIDE. [e.g. ifconfig eth0:0 <2nd public address> netmask <mask>].
2. Add entry in STATIC_INSIDE_OUTSIDE.
3. Run the firewall.

Public addresses for static conduits must be a part of the same network as the address configured on the original interface.

When mapping a network of external addresses onto a network of internal addresses, it is important to note the following:

• This case requires that both network definitions are the same size and have the same fourth octet.
• This case does not support mapping an address pool larger than a class C network (255 hosts).
• This case is the equivilent of entering each addresss in a seperate STATIC_INSIDE_OUTSIDE definition, therefor:
• Each address in the external network must be configured on an IP alias.

Note: If you are using FIREWALL_IP, then IP Aliases should be created on the DMZ interface. This will allow the STATIC_INSIDE_OUTSIDE definitions to be available from the DMZ, and special routes in your next-hop router, required for FIREWALL_IP, will allow traffic to flow through the Linux firewall correctly.

Using Command Line Arguments

Use the 'clear' argument to completely unload all firewall rules from the system.

./rc.firewall clear

The following arguments deal with saving/loading a configuration to/from a separate file. This will only be needed by advanced users. The 'save' argument intelligently saves critical configuration information to /etc/firewall.conf. If you append an optional filename, it will write to that file. This file is relative to your current working directory, NOT the location of rc.firewall, so you might want to pass it a fully qualified path.

./rc.firewall save [filename]
./rc.firewall load [filename]

Configuration files written by older versions of rc.firewall (versions 2.0rc4 and up) can be updated to the latest external configuration format with the 'update' command line argument and can also be passed an optional filename if you wish to update a file other than the default /etc/firewall.conf.

./rc.firewall update [filename]

The script does support SysV style initialization. The 'start' and 'restart' arguments are equivalent to using no arguments at all and 'stop' has the same effect as 'clear'.

./rc.firewall start
./rc.firewall stop
./rc.firewall restart

If you only wish to do sanity checking without actually enabling the firewall you can use the 'check' argument.

./rc.firewall check

"fast mode" allows you to bypass sanity checking operations and configure your firewall very rapidly. This is especially useful for slower computers or complicated firewall configurations that take a long time to sift through the extremely thorough sanity checking operation. Because of the lack of system inspection, this option is only for systems with a completely static configuration, i.e. no planned hardware or network configuration changes. This option operates in a similar manner to the 'load' CLA above and requires an external configuration file to work. Therefore you must run './rc.firewall save' to save your firewall configuration before you will be able to use the 'fast' argument. If you edit the firewall.conf file by hand, make sure you run './rc.firewall update' before using fast mode. As with the other options, if you want to use a configuration file saved to a location other than the default /etc/firewall.conf, then you can specify this location the command line.

./rc.firewall fast [filename]

The DUMP_TCP_ON_INIT option leaves extra rules in your firewall configuration which are unnecessary after the offending connections have been dropped. These rules can be expunged from the running firewall configuration using the 'cleanup' command line argument. Running './rc.firewall cleanup' has no other effect on the current firewall configuration.

./rc.firewall cleanup

The Art of Access Control

Outbound access control is divided up into five layers. While this method may not be as elegant as a pure access-list, it is simple and covers most applicable scenarios. Here are the layers:

1. Packets inbound internal interfaces are blocked by default.
   
2. Packets are allowed if they have a source address from a routed network. (see below)
   
3. Packets are blocked if they match criteria found in DENY_OUTBOUND.
   
4. Packets are allowed if they are from a host or network listed in PERMIT.
   
5. Packets are blocked if they are to or from an address or network listed in BLACKLIST.

Selecting Packets to Route

Adding an interface to the INTERNAL_INTERFACES directive will permit routing based on the following criteria:

1. The packet is received on an internal interface and its source address is from the network to which that interface is connected. The network is determined by meshing the ip address and netmask of the interface obtained from the output of 'ifconfig' for all IP addresses assigned to the interface.
   -or-
2. The packet is received from a network or host listed in ADDITIONAL_ROUTED_NETWORKS and is received on any internal interfaces.
   -or-
3. The packet is received on an internal interface that is listed as a dynamic interface. In this case, ALL connections received on the interface are permitted, regardless of source address.

Another feature of the firewall is the ability to assign IP aliases to a static external interface (anything not listed as an internal interface) and then list the interface as a dynamic interface. The result is that the firewall consults the kernel routing table to determine what address to use when doing source NAT on the outgoing connections. This is because the 'MASQUERADE' target is used on dynamic interfaces, in lieu of the 'SNAT' target. In short, if you have multiple IP addresses, you can change your identity based on where you are connecting.

Port Forwarding

One of the most advanced features of the Projectfiles.com Linux Firewall is the port forwarding implementation. The beauty is in the way it handles the issue of how port forwarding breaks down when the destination host is on the same network as the originating host. Normally you would have to source NAT (in addition to destination NAT) every packet that is forwarded in order to accommodate this particular situation. The reason for this is to prevent a routing triangle where the destination host replies to originating host directly and the originating host discards the reply because it does not recognize the source address -- since connection tracking did not demasquerade the packet because it did not pass through the firewall on its return path. To source NAT all packets would fix the triangular routing problem, but it also masks the true source address for ALL port forwarded connections passing through the firewall. For many applications, this behavior is not acceptable (think: internal webserver). The obvious solution is to source NAT only port forwarding packets which go out the same interface they came in on. This would be simple if we could do something like:

iptables -t nat -A POSTROUTING -<stuff_to_match_port_forwards> \
         -i eth0 -o eth0 -j SNAT --to-source <interface_ip_address>

Note that version 2.0rc5 will only port forward packets destined for the base address of external interfaces due to the availability of the new STATIC_INSIDE_OUTSIDE directive.

Route Verification

Route verification is the practice of discarding packets received on an interface which does not expect to those handle traffic from the given source address. This is not actually part of netfilter, but it is handled further down in the part of the Linux kernel that does routing. Route verification can be enabled through the proc filesystem [/proc/sys/net/ipv4/conf/*/rp_filter]. Enabling route verification, also called reverse path filtering [hence rp_filter], can prevent some forms of spoofing. For example, if a firewall allows connections from 192.168.0.10 but does not specify through which interface the packet must be received on (under the assumption that only a host inside the firewall would provide such a source address), then the firewall could be vulnerable to connections from a host outside the local network claiming to be 192.168.0.10. As of 2.0rc3 the firewall automatically enables kernel level reverse path filtering on all interfaces unless they are specified in the NO_RP_FILTER_INTERFACES directive. The firewall has always done some amount of route verification though explicitly specifying inbound interfaces whenever possible.

Instances where you might need to disable route verification include:

1. If you want to do asymmetric routing (accepting returning packets inbound an interface other than the outbound interface).
2. If the box has multiple interfaces up on the same network.
3. If you are using special VPN interfaces to tunnel traffic (e.g. FreeS/WAN)